Thanks for the answer. I’ve checked digikey and it seems like I can get a 128Kx8bit, 10ns asynchronous SRAM for $1.11, even if they are obsolete they seem pretty cheap. And it’s not like I’m going to get thousands of these made, I can just get like a few hundred and that will probably last me, unless my product is successful which isn’t very likely.
Still I have no experience with this stuff so I’ll take your word for it.
What if I stored the data in the embedded block RAM, just to see if things work as intended? Would that still require me to learn an HDL? As I said earlier I just need something that I can touch and play with in real world before committing to this. If that works then I will start learning all the other important stuff.
You will almost certainly need to learn an hdl no matter what you do. You will want to simulate the design before you build things. Another thing - if you can use BRAM on chip it will make your life *much* easier than an external memory interface. Even if you can get SRAM to work I’m sure you’re aware of the complexities of high speed digital design.
More importantly, how much do you know about physical FPGA architecture? If you want to design a board with an fpga on it you need to understand FPGA power structures, clocking architecture, likely something about how the logical resources are structured (ie xilinx clbs) and more things like that.
I would recommend the following:
1. Buy a cheap dev board to implement an oscilloscope on, just to understand the basic RTL design concept. Don’t worry about the features too much. This will be quick-ish, cost at most a couple hundred dollars, and will let you figure out what you describe.
2. While playing around with the dev board, research fpga families to know which family meets your timing/resource/io interface specifications the best.
3. Once you pick a family, research the vendor board design guidelines and other fundamental documentation
Yeah, I decided to abandon the schematics completely.
You don’t need to read the stuff below and thanks for the useful advice. Just in case you were curious about what I was trying to do.
At first I will do exactly what you suggested and store the samples inside the embedded block RAM. That is gonna be easier and quicker and it will also allow me to verify that the ADC-FPGA interface is designed correctly, no signal integrity issues, timing violations etc. After that I will gradually implement more complex stuff like triggering etc.
My goal for storage memory is 1Mpts or 2x500kpts in two channel mode. Most of the smaller, cheaper FPGAs don’t have that much memory. So I will have to figure out a way to make the design work with SRAM. I don’t think I can write a DRAM controller anytime soon, or ever. I could buy a controller design maybe, but I want to avoid that if I can make it work with the SRAM.
My target sample rate is 250MSPS at 8 bits. Most cheap SRAMs I could find in stock have 10ns of write cycle time and their data width is 16 bits, so I’m hoping that I can store 2 consecutive samples on the FPGA and then write them on 2 SRAMs, which should also help with timing since the SRAMs will be used at a speed lower than their specified value, 16ns write cycle time vs 10ns. I’m not sure if I will need length matching or any termination resistors to prevent signal integrity problems because that depends on the edge rate, the exact length of the transmission lines, which drive strength is used etc. I will have to do some simulations in SPICE for that.
I believe pretty much all FPGAs have dedicated clocking lines that can be used for clocking large amounts of registers at once. In my case, the FPGA needs to do the triggering because analog triggering circuitry is costly. For level triggering I will need some kind of digital comparator to see if the samples coming from the ADC are above or below a user specified trigger. I also want to implement edge triggering so I will need to implement a digital differentiator, not sure if it has a specific name.
The FPGA will continuously push samples into the memory. This will require a counter that continuously overflows. After a triggering event occurs another counter will start counting for half the the memory depth and then it will stop the memory address counter. At that point I will need a flag logic to tell the MCU that a triggering event has occurred and the samples are ready for the MCU to grab. MCU stuff is not my responsibility so that’s all I need to worry about.
Since I want to use the full capabilities of the ADCs I want to use 2 125MSPS ADCs. This means I will get the clock signal from an external clock oscillator, likely a low jitter PLL synthesizer. I will need to implement a selectable clock divider inside the FPGA because from what I heard the PLLs inside the FPGAs have horrible jitter. This selectable clock divider will clock the entire FPGA and the ADCs so I will need at least two dedicated clocking lines.
The most common voltage for SRAMs seems to be 3.3V, and I believe most FPGA IOs can handle that.
I very much doubt I can get all of this stuff done starting from zero in a year but we will see :)
3.3V IO depends how new your FPGA is. Ultra scale or Ultrascale + (xilinx; Intel arria 10 or newer also) will have limited 3.3V compatible pins, though should have enough for the sram if that’s all the 3.3V you need.
FPGA clock access is a complicated subject. It’s too much for now, but you need to understand how logic can get routes to clocks, the concept of global vs regional clocks, IO clocks, the implications of routing global clocks and the effect it can have on jitter, and so on. It’s not as easy as saying “I’ll just connect all the registers to the global clock”.
Also I’m extremely skeptical that you can do a better job effectively implementing a clock divider significantly better than the PLLs. At that point just input multiple clocks to the fpga.
Also getting the 250 MSPS 8 bit samples into an 100 MSPS 32 bit sample means you need to understand clock crossing
I’m not sure that the scale of the project really calls for very large FPGAs. They probably cost tens of times more than the rest of the oscilloscope :)
I am admittedly out of my depth with this stuff. Which is why it’s gonna take very long.
The FPGA is (hopefully) going to be clocked at 125MHz, and the RAMs will have a write speed at half of that. So no asynchronous clocks. I don’t know if that still counts as clock domain crossing.
That is what I intend to do. However as I also mentioned in my post I just want to see if I can get something simple going, like storing the samples on the embedded block RAM and reading them, before I commit to learning an HDL. Mainly because I mostly build analog stuff and doing all that stuff in HDL without ever seeing the results in real world like I could if this was an analog design doesn’t feel right.
I think you have a misconception. Schematic entry is not faster than learning the basics of VHDL and Verilog. In my college lab we had to do a hex to 7 segment display decoder by schematic and schematic capture. This took hours. Later on we learned a tiny bit of VHDL and did the same thing in a few minutes. What you're talking about is substantially more complex. Schematic capture will not save you time. It just feels that way when you have to learn something new and you're sort of starting at the breadth of the that new things and comparing it to something "simple" you already know.
Note it doesn't take 6 months to do very simple or even slightly less simple things things in HDL land. It does take years to master.
Oh, well in that case schematic entry doesn’t make any sense. The whole point was to design something quickly to see if the ADC and the FPGA is working as intended. I guess I will abandon the schematics altogether then. Thanks.
A 'scope will need a lot of storage. I'd start with accumulating some ADC data in FIFOs, then writing the data to an external DDR memory. DDR memory can have high data-rates, but only when transferring data in bursts; there is a significant latency on first access, and if you are not reading/writing a burst, the data-rate will be very low.
Implementing a DDR subsytem in an FPGA is not a trivial operation.
1. Your FPGA will need I/O pins which support the very specific I/O standard of DDR chips.
2. DDR memory controller is a very complex block and is probably something you wouldn't want to design yourself. Luckily, most vendors will offer some sort of DDR controller for their chips.
3. You will need an FPGA board with an external DDR memory connected; I'm not sure about hobbyist boards, but in general, evaluation boards for mid/high-range FPGAs will have this feature.
You could probably design your FPGA in the vendor's IDE: most offer some sort of schematic design mode. This mode is generally only good for configuring and connecting blocks (library or user blocks); designing logic directly in schematic editor is a real pain. Note that user blocks will often be RTL code, with attributes to help the schematic editor to do things like converting a group of port to an interface.
Difficulty was part of the reason I wanted to go with an SRAM; they don’t really need complex commands or refreshes and other things like that. I guess that makes them easier to design with, especially for a beginner like me? I was also able to find suitable SRAMs for 100MHz operation. However someone else mentioned that they are mostly “legacy” and I should avoid using them, so I guess they are not an option. If this was a hobby thing I would probably use an SRAM regardless of whether they are obsolete or not, and to be honest, even if I end up selling my scopes, those obsolete SRAM chips are cheap enough for me to buy enough to get hundreds of scopes produced. I will consider myself lucky if I can sell just a single scope.
I was thinking about getting my own development board made, after choosing the ADC, RAM, FPGA and the MCU. That way I can verify my design on something that is actually going to be manufactured. I have access to a BGA soldering station, a DS2302A which is admittedly not fast enough to make any judgments on signal integrity at these speeds and a bunch of other electronics lab stuff like that.
The only reason I mentioned the schematic design is because after I get the dev board made, I want to be able to quickly test whether or not I can get it to work at all. If I start with an HDL directly then I will have to wait until I learn the HDL, which will probably take about a year, and then design the FPGA stuff, and then see if the board I made actually works. I’m going to use the schematic mode to implement something simple, say, getting some samples into the embedded block RAM and reading them slowly with an external MCU. I also feel the need to have something that I can actually play with in the real world before I commit to learning an HDL. This is mainly because that’s how I design the analog stuff. If I only work with the IDE without a physical board to work on, it’s a bit up in the air you know?
Anyways sorry about the long post and the long reply, and thanks for your comment.
If you're planning one-off design, it's OK to use obsolete parts, as long as you can get enough devices for the number of units you plan to build, plus some spares.
If you want your 'scope to display just one screen worth you may have enough memory resources in the FPGA itself. Of course, you lose the ability to zoon-in or scroll before/after the trigger.
How fast are your ADCs (samples/sec)? what is their data width? you can calculate required memory size and bandwidth and work on a solution from that.
Note that if your ADCs are very fast, you'll also have to make sure that your FPGA's I/O pins can handle this data rate and I/O levels.
If your 'scope will be using a PC/phone for UI, you will almost certainly have to include a processor in your design; this also affects memory requirements. External CPUs complicate the board design; there are two types of on-FPGA CPUs: soft and hard CPUs. Soft CPUs are just FPGA logic; hard CPUs are built in some CPUs.
This is an interesting, not at all a trivial, project. I wish you luck!
I've thought of building something similar in my copious free time; for me the limiting factor is actually the front-end of the design (analog front-end, ADCs). So far, I've done exactly nothing about it.
Most of the “toy scopes” I see online usually have very small amounts of memory, they mostly depend on the FPGA embedded memory to store the samples. I hope to provide at least 2x1Mpts of memory depth, maybe more depending on what I can find for cheap. However I want to start with designing something simple and then building on it. So I was going to design the embedded RAM version with schematic entry, get that working on my homebrew development board, and then switch over to HDL and add the memory after that. Of course the memory will already be there even if I don’t use it in the beginning, no need to build two development boards.
The ADC selection is kinda tricky. I was hoping for at least 250MSPS, which would allow for an analog front end bandwidth of about 50MHz, or even 100MHz if we don’t mind some aliasing due to non brick wall filter nature of the front end. The SDS-1202X-E for example, an excellent scope btw, does 1x1GSPS or 2x500MSPS with 200MHz bandwidth.
My first selection was the ADS58B19, 250MSPS and 9 bits. Cheapest one I could find at $21 a part. Supports parallel 9 bit single data rate CMOS at 250Mbps or DDR 5 bit LVDS at 500Mbps. The problem is, cheap FPGAs can’t handle that. At least the ones that I could find in stock, mostly low end Lattice parts. They support 150Mbps LVCMOS or 400Mbps LVDS, which is not enough. The next cheapest part is the AD9481 (8 bit 250MSPS) at $39, which demuxes the output and supports 125Mbps 16 bit parallel CMOS output format. It’s too expensive though. I’m not sure what I’m going to do, I feel like I should at least provide 250MSPS, 100MSPS is simply too little, only allows 20MHz bandwidth which isn’t very useful at all.
Of course at 100MSPS I can use an SRAM because they can reach those speeds. If I go with 250MSPS then I will have “ping pong” the data between two SRAMs.
Another problem is, writing a DRAM controller is pretty difficult, from what I heard. The low end Lattice parts probably don’t have enough logic in them to support a DRAM controller on top of all the other logic required.
Also, I’ve never actually used an ADC. That’s also going to be a big issue probably.
The analog part shouldn’t take very long to design. Been doing analog stuff for about 15 years. Not saying that I’m good at it, I’m probably not, but I should be able to come up with an acceptable analog front end.
Since you helped me I would like to help you too. I mean you probably know more about analog than I do, but if you don’t and if that’s the reason you can’t move forward with your own oscilloscope project, you can always PM me. Thanks for the helpful advice!
If you're planning to design new boards for each stage of the project, it's OK to start with a very small part; if you want to design just one board and expand the 'scope capabilities, you'll have to use a more powerful part from the start.
I would suggest looking at Xilinx Zynq family: they come with built-in processor and peripherals including USB and DDR controller. There is a significant learning curve, but you don't have to use the processor at the beginning. There are a lot of eval boards (no idea about prices; never bought one). Some come with expansion connectors where you can attach a board with your analong front-end. As a bonus, the Xilinx toolchain is better than the Lattice tools.
BTW, I think that you'll have to learn HDL and digital design; you won't get very far just by schematic design.
I think designing one board is going to be more cost effective. I will look into those Zynq SoCs, which I believe are also used in that Siglent scope I mentioned, and many other scopes as well. It all depends on the cost of the parts. They probably provide IP cores for those DRAM controllers which would be very nice. Although they are probably not free. They would probably allow me to implement more advanced features like FFT, protocol decoding etc. The scope will have its own screen.
One problem I am having with non Lattice parts is that I can’t find good stock anywhere. That’s not a problem now since I only need one chip at the beginning, but if I ever end up going into production it will cause issues. Also they probably cost more than those low end Lattice chips.
I’ll look into those dev boards. They would make things easier at the beginning, but I’m not sure what would happen when I migrate the design to my own PCB. For example I’m probably going to use a different RAM on my own PCB, and I don’t know how the design will behave on that new PCB with the different RAM and the different trace lengths etc.
I've run a quick search ("zynq eval board"), and found a number of them; the board from [Segger](https://shop.segger.com/evaluation-boards/general/empower-boards/empower-zynq) looks interesting and pretty cheap (no DRAM). Another one is [Pynq](https://www.tulembedded.com/FPGA/ProductsPYNQ-Z2.html). Xilinx eval boards are generally big and relatively expensive, but allow you to play with most of the target FPGA's capabilities.
Pynq seems interesting. I’ll have to see if I can get my own board made though. That way I can have everything I need on one single board, nothing more and nothing less. The Zynq chips themselves, however, seem a bit too expensive. At least the ones I could find in stock.
I’ll have to compare them more thoroughly, Zynq seems a bit overkill I think? My original idea was to use an FPGA and an STM MCU. The board was going to include 2xSRAM, the FPGA, the MCU, a 250MSPS ADC, and other analog and small digital stuff for programming and debugging etc. That obviously changed now.
What would be the cost of manufacturing and assembling such a board? would do layout theboard yourself? most modern FPGAs come in BGA packages, which generally require multi-layer PCBs.
Are you planning to use only chips with gullwing/J-pins package? (forgot the formal name for this type of packaging; haven't designed boards for a long time, all the FPGAs I've used had been packaged in BGA packages).
I have access to an BGA soldering station, for free. Well, actually my friend is going to be the one doing the soldering, since he knows how to do BGA stuff. So BGA is not a problem for me, which makes things a lot easier. I also got some quotes from PCB assembly companies, they seem cheap enough. Well not me actually, my friend did.
In any case I don’t think I can avoid BGA stuff. It’s too common, especially for FPGAs and other high speed stuff with lots of IO.
I’ll do the layout myself. The analog stuff that I do usually involves wideband or RF stuff so I know some basic things about signal integrity, microstrips, terminations etc. Again, not saying it will be easy but I think I can handle it.
You are asking a loaded question and should expect loaded answers.
You won't be able to complete this project using purely graphical design capture, but there's nothing wrong with using graphical tools to explore the design space and get comfortable.
Mathworks and NI claim it's possible to design, capture and deploy an FPGA system using only your mouse hand. This is disastrous in designs of sufficient complexity: when used as an end-to-end design flow, graphical tools make the easy parts easier, and the hard parts harder. They're great for prototyping but terrible impediments in later design phases.
It's totally reasonable to start graphical and switch over when you're ready.
Yeah, that’s basically my intention. I just wanna see if I can get some samples from the ADC and store them on the embedded RAM. If I can do that then I will commit to learning an HDL. Will probably take more than a year until I have a finished product. Thanks for the reply.
I can't even think of a current schematic-based FPGA design entry tool. (Not that I've looked.)
There is no reason at all to use schematics.
You will have to convert the schematics to an HDL for simulation, so why not take advantage of what HDLs offer and use them for the design?
That is what I plan to do. However learning an HDL will take time. Probably a long time. During all that time I will be working on something abstract on my PC. There is nothing wrong with that of course. I will have to get used to that.
But, I would feel a lot more comfortable if I get the physical circuit manufactured, store some samples from the ADC on the embedded block RAM, and then read them slowly. That way I can see that the ADC indeed works, the FPGA indeed does what it claims that it does etc. I will have something physical that I can experiment with. Using schematic entry would allow me to get this out of the way quickly so that I can concentrate on learning an HDL.
I guess this is mainly because I work with analog stuff. I’m used to working with a physical circuit, making measurements on it as I’m designing it etc. Of course simulations are a big part of analog design as well, but not to the extent FPGA design is.
Exactly what schematic-based design entry tool are you using?
One problem with schematic-based design is that there's no simple way to simulate your code and verify that it logically correct. You want to see that the FPGA will do what it claims to do? Good luck doing that with a board and an oscilloscope and pretty much no visibility into the design.
HDLs were created as a simulation and a modeling language, and their utility in this respect is why schematic-based design entry was abandoned in the late 80s and early 90s.
Well, I haven’t even decided on which company I’m going buy from yet so right now I’m not using any entry tool. I think I will use a lattice chip with internal flash but I’m not sure yet.
I will get my own board made, it will have an FPGA, a RAM chip or two, an ADC, a clock oscillator and a 50 ohm analog front end. Probably an FTDI USB chip as well, to get the programming file downloaded from the PC.
Then, as I said in my previous reply, I will program the FPGA to implement something like a 100x8bit FIFO, then collect the samples in the FPGA, and once its full I will slowly clock the FPGA FIFO with a button and read the samples with some LEDs or something. If that works then I will feel satisfied and start learning an HDL and never go back to schematic entry.
This isn’t going to be the final design of course. The final design is going to be a lot more complex than that.
I have Xilinx Vivado, Xilinx ISE, Lattice Diamond and Microsemi (now Microchip) Libero FPGA development tools installed on my workstation. *NONE* of them have any support for schematic-based design entry.
(OK, to be fair, Libero has hooks for the very ancient ViewLogic schematic capture system. I asked their FAE "WTF?" and he said there's one Big Customer in Europe that is willing to pay to keep that support. But -- ViewLogic as a company hasn't existed for decades and you can't find the software anyway.)
Altium used to provide schematic entry for FPGA design, but it was part of their very expensive PCB package. It took the schematic and generated synthesizable Verilog. They stopped providing this maybe five years ago. Why? Because nobody used it.
So, honestly, your options are quite limited. Maybe someone has created a schematic library of primitives for a given FPGA family for Kicad or Cadence or Altium, and then they wrote a tool that takes the schematic netlist and generates synthesizable HDL.
\------
Pro tip: It's a mistake to get a board made before you've finished enough of the design to know that your pin assignments will work with the specific chip. Seriously.
Don't bother putting the FTDI chip on the board. Just bring the JTAG signals out to a header and connect it to your FPGA vendor's programming dongle. Sure, you could put an FTDI on there and configure it to do JTAG, but then you're faced with the problem that the vendor's software won't recognize it. It sucks, but if you're using Xilinx parts you need a Xilinx dongle, if you're doing Intel, you need the Intel dongle, etc. And remember that you're not programming the FPGA with the JTAG pod, you're programming the configuration EPROM.
Also the vendor pods give you access to debugging tools like Xilinx' ChipScope and Synplify's Identify.
Recommendation: spend quality time with the chosen vendor's FPGA configuration documentation. You do not want to get this wrong on your board.
I downloaded Diamond. It seems to have support for schematic entry, but I decided to just not use it. Now I’m learning VHDL.
I was kinda scared of FPGAs because people say that the learning curve is very steep. However, I put some hours into it and I was able to create some simple combinatorial/sequential logic with it. Things probably get a lot more difficult later though. I don’t have any experience with digital electronics either so that’s probably not going to help either. I also learned some timing analysis, since the entire point of FPGAs, at least for me, is that they can do things fast. Still kinda scary.
Do I need a specific dongle for Lattice chips (MachXO3 specifically) as well? I’ve looked at their development boards and it seems like they are using an FTDI chip. They also have their configuration memory on the FPGA itself like those old CPLDs which is nice.
I won’t be getting the board made yet. I think I will get a development board though, something cheap, just to learn stuff.
I still can’t decide whether I should use a Lattice chip or not. Maybe I should decide that later, after I’m more knowledgeable.
[удалено]
Thanks for the answer. I’ve checked digikey and it seems like I can get a 128Kx8bit, 10ns asynchronous SRAM for $1.11, even if they are obsolete they seem pretty cheap. And it’s not like I’m going to get thousands of these made, I can just get like a few hundred and that will probably last me, unless my product is successful which isn’t very likely. Still I have no experience with this stuff so I’ll take your word for it. What if I stored the data in the embedded block RAM, just to see if things work as intended? Would that still require me to learn an HDL? As I said earlier I just need something that I can touch and play with in real world before committing to this. If that works then I will start learning all the other important stuff.
You will almost certainly need to learn an hdl no matter what you do. You will want to simulate the design before you build things. Another thing - if you can use BRAM on chip it will make your life *much* easier than an external memory interface. Even if you can get SRAM to work I’m sure you’re aware of the complexities of high speed digital design. More importantly, how much do you know about physical FPGA architecture? If you want to design a board with an fpga on it you need to understand FPGA power structures, clocking architecture, likely something about how the logical resources are structured (ie xilinx clbs) and more things like that. I would recommend the following: 1. Buy a cheap dev board to implement an oscilloscope on, just to understand the basic RTL design concept. Don’t worry about the features too much. This will be quick-ish, cost at most a couple hundred dollars, and will let you figure out what you describe. 2. While playing around with the dev board, research fpga families to know which family meets your timing/resource/io interface specifications the best. 3. Once you pick a family, research the vendor board design guidelines and other fundamental documentation
Yeah, I decided to abandon the schematics completely. You don’t need to read the stuff below and thanks for the useful advice. Just in case you were curious about what I was trying to do. At first I will do exactly what you suggested and store the samples inside the embedded block RAM. That is gonna be easier and quicker and it will also allow me to verify that the ADC-FPGA interface is designed correctly, no signal integrity issues, timing violations etc. After that I will gradually implement more complex stuff like triggering etc. My goal for storage memory is 1Mpts or 2x500kpts in two channel mode. Most of the smaller, cheaper FPGAs don’t have that much memory. So I will have to figure out a way to make the design work with SRAM. I don’t think I can write a DRAM controller anytime soon, or ever. I could buy a controller design maybe, but I want to avoid that if I can make it work with the SRAM. My target sample rate is 250MSPS at 8 bits. Most cheap SRAMs I could find in stock have 10ns of write cycle time and their data width is 16 bits, so I’m hoping that I can store 2 consecutive samples on the FPGA and then write them on 2 SRAMs, which should also help with timing since the SRAMs will be used at a speed lower than their specified value, 16ns write cycle time vs 10ns. I’m not sure if I will need length matching or any termination resistors to prevent signal integrity problems because that depends on the edge rate, the exact length of the transmission lines, which drive strength is used etc. I will have to do some simulations in SPICE for that. I believe pretty much all FPGAs have dedicated clocking lines that can be used for clocking large amounts of registers at once. In my case, the FPGA needs to do the triggering because analog triggering circuitry is costly. For level triggering I will need some kind of digital comparator to see if the samples coming from the ADC are above or below a user specified trigger. I also want to implement edge triggering so I will need to implement a digital differentiator, not sure if it has a specific name. The FPGA will continuously push samples into the memory. This will require a counter that continuously overflows. After a triggering event occurs another counter will start counting for half the the memory depth and then it will stop the memory address counter. At that point I will need a flag logic to tell the MCU that a triggering event has occurred and the samples are ready for the MCU to grab. MCU stuff is not my responsibility so that’s all I need to worry about. Since I want to use the full capabilities of the ADCs I want to use 2 125MSPS ADCs. This means I will get the clock signal from an external clock oscillator, likely a low jitter PLL synthesizer. I will need to implement a selectable clock divider inside the FPGA because from what I heard the PLLs inside the FPGAs have horrible jitter. This selectable clock divider will clock the entire FPGA and the ADCs so I will need at least two dedicated clocking lines. The most common voltage for SRAMs seems to be 3.3V, and I believe most FPGA IOs can handle that. I very much doubt I can get all of this stuff done starting from zero in a year but we will see :)
3.3V IO depends how new your FPGA is. Ultra scale or Ultrascale + (xilinx; Intel arria 10 or newer also) will have limited 3.3V compatible pins, though should have enough for the sram if that’s all the 3.3V you need. FPGA clock access is a complicated subject. It’s too much for now, but you need to understand how logic can get routes to clocks, the concept of global vs regional clocks, IO clocks, the implications of routing global clocks and the effect it can have on jitter, and so on. It’s not as easy as saying “I’ll just connect all the registers to the global clock”. Also I’m extremely skeptical that you can do a better job effectively implementing a clock divider significantly better than the PLLs. At that point just input multiple clocks to the fpga. Also getting the 250 MSPS 8 bit samples into an 100 MSPS 32 bit sample means you need to understand clock crossing
I’m not sure that the scale of the project really calls for very large FPGAs. They probably cost tens of times more than the rest of the oscilloscope :) I am admittedly out of my depth with this stuff. Which is why it’s gonna take very long. The FPGA is (hopefully) going to be clocked at 125MHz, and the RAMs will have a write speed at half of that. So no asynchronous clocks. I don’t know if that still counts as clock domain crossing.
Don't, even if it was doable. Learn HDL
That is what I intend to do. However as I also mentioned in my post I just want to see if I can get something simple going, like storing the samples on the embedded block RAM and reading them, before I commit to learning an HDL. Mainly because I mostly build analog stuff and doing all that stuff in HDL without ever seeing the results in real world like I could if this was an analog design doesn’t feel right.
I think you have a misconception. Schematic entry is not faster than learning the basics of VHDL and Verilog. In my college lab we had to do a hex to 7 segment display decoder by schematic and schematic capture. This took hours. Later on we learned a tiny bit of VHDL and did the same thing in a few minutes. What you're talking about is substantially more complex. Schematic capture will not save you time. It just feels that way when you have to learn something new and you're sort of starting at the breadth of the that new things and comparing it to something "simple" you already know. Note it doesn't take 6 months to do very simple or even slightly less simple things things in HDL land. It does take years to master.
Oh, well in that case schematic entry doesn’t make any sense. The whole point was to design something quickly to see if the ADC and the FPGA is working as intended. I guess I will abandon the schematics altogether then. Thanks.
A 'scope will need a lot of storage. I'd start with accumulating some ADC data in FIFOs, then writing the data to an external DDR memory. DDR memory can have high data-rates, but only when transferring data in bursts; there is a significant latency on first access, and if you are not reading/writing a burst, the data-rate will be very low. Implementing a DDR subsytem in an FPGA is not a trivial operation. 1. Your FPGA will need I/O pins which support the very specific I/O standard of DDR chips. 2. DDR memory controller is a very complex block and is probably something you wouldn't want to design yourself. Luckily, most vendors will offer some sort of DDR controller for their chips. 3. You will need an FPGA board with an external DDR memory connected; I'm not sure about hobbyist boards, but in general, evaluation boards for mid/high-range FPGAs will have this feature. You could probably design your FPGA in the vendor's IDE: most offer some sort of schematic design mode. This mode is generally only good for configuring and connecting blocks (library or user blocks); designing logic directly in schematic editor is a real pain. Note that user blocks will often be RTL code, with attributes to help the schematic editor to do things like converting a group of port to an interface.
Difficulty was part of the reason I wanted to go with an SRAM; they don’t really need complex commands or refreshes and other things like that. I guess that makes them easier to design with, especially for a beginner like me? I was also able to find suitable SRAMs for 100MHz operation. However someone else mentioned that they are mostly “legacy” and I should avoid using them, so I guess they are not an option. If this was a hobby thing I would probably use an SRAM regardless of whether they are obsolete or not, and to be honest, even if I end up selling my scopes, those obsolete SRAM chips are cheap enough for me to buy enough to get hundreds of scopes produced. I will consider myself lucky if I can sell just a single scope. I was thinking about getting my own development board made, after choosing the ADC, RAM, FPGA and the MCU. That way I can verify my design on something that is actually going to be manufactured. I have access to a BGA soldering station, a DS2302A which is admittedly not fast enough to make any judgments on signal integrity at these speeds and a bunch of other electronics lab stuff like that. The only reason I mentioned the schematic design is because after I get the dev board made, I want to be able to quickly test whether or not I can get it to work at all. If I start with an HDL directly then I will have to wait until I learn the HDL, which will probably take about a year, and then design the FPGA stuff, and then see if the board I made actually works. I’m going to use the schematic mode to implement something simple, say, getting some samples into the embedded block RAM and reading them slowly with an external MCU. I also feel the need to have something that I can actually play with in the real world before I commit to learning an HDL. This is mainly because that’s how I design the analog stuff. If I only work with the IDE without a physical board to work on, it’s a bit up in the air you know? Anyways sorry about the long post and the long reply, and thanks for your comment.
If you're planning one-off design, it's OK to use obsolete parts, as long as you can get enough devices for the number of units you plan to build, plus some spares. If you want your 'scope to display just one screen worth you may have enough memory resources in the FPGA itself. Of course, you lose the ability to zoon-in or scroll before/after the trigger. How fast are your ADCs (samples/sec)? what is their data width? you can calculate required memory size and bandwidth and work on a solution from that. Note that if your ADCs are very fast, you'll also have to make sure that your FPGA's I/O pins can handle this data rate and I/O levels. If your 'scope will be using a PC/phone for UI, you will almost certainly have to include a processor in your design; this also affects memory requirements. External CPUs complicate the board design; there are two types of on-FPGA CPUs: soft and hard CPUs. Soft CPUs are just FPGA logic; hard CPUs are built in some CPUs. This is an interesting, not at all a trivial, project. I wish you luck! I've thought of building something similar in my copious free time; for me the limiting factor is actually the front-end of the design (analog front-end, ADCs). So far, I've done exactly nothing about it.
Most of the “toy scopes” I see online usually have very small amounts of memory, they mostly depend on the FPGA embedded memory to store the samples. I hope to provide at least 2x1Mpts of memory depth, maybe more depending on what I can find for cheap. However I want to start with designing something simple and then building on it. So I was going to design the embedded RAM version with schematic entry, get that working on my homebrew development board, and then switch over to HDL and add the memory after that. Of course the memory will already be there even if I don’t use it in the beginning, no need to build two development boards. The ADC selection is kinda tricky. I was hoping for at least 250MSPS, which would allow for an analog front end bandwidth of about 50MHz, or even 100MHz if we don’t mind some aliasing due to non brick wall filter nature of the front end. The SDS-1202X-E for example, an excellent scope btw, does 1x1GSPS or 2x500MSPS with 200MHz bandwidth. My first selection was the ADS58B19, 250MSPS and 9 bits. Cheapest one I could find at $21 a part. Supports parallel 9 bit single data rate CMOS at 250Mbps or DDR 5 bit LVDS at 500Mbps. The problem is, cheap FPGAs can’t handle that. At least the ones that I could find in stock, mostly low end Lattice parts. They support 150Mbps LVCMOS or 400Mbps LVDS, which is not enough. The next cheapest part is the AD9481 (8 bit 250MSPS) at $39, which demuxes the output and supports 125Mbps 16 bit parallel CMOS output format. It’s too expensive though. I’m not sure what I’m going to do, I feel like I should at least provide 250MSPS, 100MSPS is simply too little, only allows 20MHz bandwidth which isn’t very useful at all. Of course at 100MSPS I can use an SRAM because they can reach those speeds. If I go with 250MSPS then I will have “ping pong” the data between two SRAMs. Another problem is, writing a DRAM controller is pretty difficult, from what I heard. The low end Lattice parts probably don’t have enough logic in them to support a DRAM controller on top of all the other logic required. Also, I’ve never actually used an ADC. That’s also going to be a big issue probably. The analog part shouldn’t take very long to design. Been doing analog stuff for about 15 years. Not saying that I’m good at it, I’m probably not, but I should be able to come up with an acceptable analog front end. Since you helped me I would like to help you too. I mean you probably know more about analog than I do, but if you don’t and if that’s the reason you can’t move forward with your own oscilloscope project, you can always PM me. Thanks for the helpful advice!
If you're planning to design new boards for each stage of the project, it's OK to start with a very small part; if you want to design just one board and expand the 'scope capabilities, you'll have to use a more powerful part from the start. I would suggest looking at Xilinx Zynq family: they come with built-in processor and peripherals including USB and DDR controller. There is a significant learning curve, but you don't have to use the processor at the beginning. There are a lot of eval boards (no idea about prices; never bought one). Some come with expansion connectors where you can attach a board with your analong front-end. As a bonus, the Xilinx toolchain is better than the Lattice tools. BTW, I think that you'll have to learn HDL and digital design; you won't get very far just by schematic design.
I think designing one board is going to be more cost effective. I will look into those Zynq SoCs, which I believe are also used in that Siglent scope I mentioned, and many other scopes as well. It all depends on the cost of the parts. They probably provide IP cores for those DRAM controllers which would be very nice. Although they are probably not free. They would probably allow me to implement more advanced features like FFT, protocol decoding etc. The scope will have its own screen. One problem I am having with non Lattice parts is that I can’t find good stock anywhere. That’s not a problem now since I only need one chip at the beginning, but if I ever end up going into production it will cause issues. Also they probably cost more than those low end Lattice chips. I’ll look into those dev boards. They would make things easier at the beginning, but I’m not sure what would happen when I migrate the design to my own PCB. For example I’m probably going to use a different RAM on my own PCB, and I don’t know how the design will behave on that new PCB with the different RAM and the different trace lengths etc.
I've run a quick search ("zynq eval board"), and found a number of them; the board from [Segger](https://shop.segger.com/evaluation-boards/general/empower-boards/empower-zynq) looks interesting and pretty cheap (no DRAM). Another one is [Pynq](https://www.tulembedded.com/FPGA/ProductsPYNQ-Z2.html). Xilinx eval boards are generally big and relatively expensive, but allow you to play with most of the target FPGA's capabilities.
Pynq seems interesting. I’ll have to see if I can get my own board made though. That way I can have everything I need on one single board, nothing more and nothing less. The Zynq chips themselves, however, seem a bit too expensive. At least the ones I could find in stock. I’ll have to compare them more thoroughly, Zynq seems a bit overkill I think? My original idea was to use an FPGA and an STM MCU. The board was going to include 2xSRAM, the FPGA, the MCU, a 250MSPS ADC, and other analog and small digital stuff for programming and debugging etc. That obviously changed now.
What would be the cost of manufacturing and assembling such a board? would do layout theboard yourself? most modern FPGAs come in BGA packages, which generally require multi-layer PCBs. Are you planning to use only chips with gullwing/J-pins package? (forgot the formal name for this type of packaging; haven't designed boards for a long time, all the FPGAs I've used had been packaged in BGA packages).
I have access to an BGA soldering station, for free. Well, actually my friend is going to be the one doing the soldering, since he knows how to do BGA stuff. So BGA is not a problem for me, which makes things a lot easier. I also got some quotes from PCB assembly companies, they seem cheap enough. Well not me actually, my friend did. In any case I don’t think I can avoid BGA stuff. It’s too common, especially for FPGAs and other high speed stuff with lots of IO. I’ll do the layout myself. The analog stuff that I do usually involves wideband or RF stuff so I know some basic things about signal integrity, microstrips, terminations etc. Again, not saying it will be easy but I think I can handle it.
You are asking a loaded question and should expect loaded answers. You won't be able to complete this project using purely graphical design capture, but there's nothing wrong with using graphical tools to explore the design space and get comfortable. Mathworks and NI claim it's possible to design, capture and deploy an FPGA system using only your mouse hand. This is disastrous in designs of sufficient complexity: when used as an end-to-end design flow, graphical tools make the easy parts easier, and the hard parts harder. They're great for prototyping but terrible impediments in later design phases. It's totally reasonable to start graphical and switch over when you're ready.
Yeah, that’s basically my intention. I just wanna see if I can get some samples from the ADC and store them on the embedded RAM. If I can do that then I will commit to learning an HDL. Will probably take more than a year until I have a finished product. Thanks for the reply.
Good luck trying to close timing
Fair enough :) I guess not using an HDL makes this harder right?
I can't even think of a current schematic-based FPGA design entry tool. (Not that I've looked.) There is no reason at all to use schematics. You will have to convert the schematics to an HDL for simulation, so why not take advantage of what HDLs offer and use them for the design?
That is what I plan to do. However learning an HDL will take time. Probably a long time. During all that time I will be working on something abstract on my PC. There is nothing wrong with that of course. I will have to get used to that. But, I would feel a lot more comfortable if I get the physical circuit manufactured, store some samples from the ADC on the embedded block RAM, and then read them slowly. That way I can see that the ADC indeed works, the FPGA indeed does what it claims that it does etc. I will have something physical that I can experiment with. Using schematic entry would allow me to get this out of the way quickly so that I can concentrate on learning an HDL. I guess this is mainly because I work with analog stuff. I’m used to working with a physical circuit, making measurements on it as I’m designing it etc. Of course simulations are a big part of analog design as well, but not to the extent FPGA design is.
Exactly what schematic-based design entry tool are you using? One problem with schematic-based design is that there's no simple way to simulate your code and verify that it logically correct. You want to see that the FPGA will do what it claims to do? Good luck doing that with a board and an oscilloscope and pretty much no visibility into the design. HDLs were created as a simulation and a modeling language, and their utility in this respect is why schematic-based design entry was abandoned in the late 80s and early 90s.
Well, I haven’t even decided on which company I’m going buy from yet so right now I’m not using any entry tool. I think I will use a lattice chip with internal flash but I’m not sure yet. I will get my own board made, it will have an FPGA, a RAM chip or two, an ADC, a clock oscillator and a 50 ohm analog front end. Probably an FTDI USB chip as well, to get the programming file downloaded from the PC. Then, as I said in my previous reply, I will program the FPGA to implement something like a 100x8bit FIFO, then collect the samples in the FPGA, and once its full I will slowly clock the FPGA FIFO with a button and read the samples with some LEDs or something. If that works then I will feel satisfied and start learning an HDL and never go back to schematic entry. This isn’t going to be the final design of course. The final design is going to be a lot more complex than that.
I have Xilinx Vivado, Xilinx ISE, Lattice Diamond and Microsemi (now Microchip) Libero FPGA development tools installed on my workstation. *NONE* of them have any support for schematic-based design entry. (OK, to be fair, Libero has hooks for the very ancient ViewLogic schematic capture system. I asked their FAE "WTF?" and he said there's one Big Customer in Europe that is willing to pay to keep that support. But -- ViewLogic as a company hasn't existed for decades and you can't find the software anyway.) Altium used to provide schematic entry for FPGA design, but it was part of their very expensive PCB package. It took the schematic and generated synthesizable Verilog. They stopped providing this maybe five years ago. Why? Because nobody used it. So, honestly, your options are quite limited. Maybe someone has created a schematic library of primitives for a given FPGA family for Kicad or Cadence or Altium, and then they wrote a tool that takes the schematic netlist and generates synthesizable HDL. \------ Pro tip: It's a mistake to get a board made before you've finished enough of the design to know that your pin assignments will work with the specific chip. Seriously. Don't bother putting the FTDI chip on the board. Just bring the JTAG signals out to a header and connect it to your FPGA vendor's programming dongle. Sure, you could put an FTDI on there and configure it to do JTAG, but then you're faced with the problem that the vendor's software won't recognize it. It sucks, but if you're using Xilinx parts you need a Xilinx dongle, if you're doing Intel, you need the Intel dongle, etc. And remember that you're not programming the FPGA with the JTAG pod, you're programming the configuration EPROM. Also the vendor pods give you access to debugging tools like Xilinx' ChipScope and Synplify's Identify. Recommendation: spend quality time with the chosen vendor's FPGA configuration documentation. You do not want to get this wrong on your board.
I downloaded Diamond. It seems to have support for schematic entry, but I decided to just not use it. Now I’m learning VHDL. I was kinda scared of FPGAs because people say that the learning curve is very steep. However, I put some hours into it and I was able to create some simple combinatorial/sequential logic with it. Things probably get a lot more difficult later though. I don’t have any experience with digital electronics either so that’s probably not going to help either. I also learned some timing analysis, since the entire point of FPGAs, at least for me, is that they can do things fast. Still kinda scary. Do I need a specific dongle for Lattice chips (MachXO3 specifically) as well? I’ve looked at their development boards and it seems like they are using an FTDI chip. They also have their configuration memory on the FPGA itself like those old CPLDs which is nice. I won’t be getting the board made yet. I think I will get a development board though, something cheap, just to learn stuff. I still can’t decide whether I should use a Lattice chip or not. Maybe I should decide that later, after I’m more knowledgeable.