| Products > Test Equipment |
| A High-Performance Open Source Oscilloscope: development log & future ideas |
| << < (21/71) > >> |
| nctnico:
--- Quote from: tom66 on November 19, 2020, 09:01:57 pm ---The Zynq 7014S has 40k LUTs + ARM processor + hard DDR controller fabric. 1 unit starting from $89 USD. IMO that wins over the 65k LUTs + no hardcore CPU + no DDR3 controller in the Kintex 70T -- and in my experience the MIG eats up easily 20% of the logic area for just a single channel DDR3 controller, I'm not convinced that would be a worthwhile trade off here. By the time you've implemented everything that the Zynq gives you "for free" (including 256KB of fast on-chip RAM) you're stepping up several grades of 'pure FPGA' to get there. --- End quote --- Well, that was the old MIG and that made me roll my own (way more resource efficient) DDR2 controller a long time ago. The hard IP DDR3 controllers in modern Xilinx FPGA devices however don't eat any logic. Realistically you can't create a DDR3 controller running at hundreds of MHz from generic IOB cells anyway. The timing needs to be trained etc. And since the Kintex 7 series is related to the Zync series it has exactly the same (hard IP) memory controller as the Zync has. The distributed oscilloscope design I have made for one of my customers based on a Spartan6 LX45T (which has 44k logic cells) contains an LM32 soft-core, timing logic, network interface + hardware firewall (don't ask me why that is in there), various peripherals and ofcourse the oscilloscope part. This design uses about half of the logic without doing much on optimisation. The smallest Kintex part has 65k logic cells. I really don't think running out of logic resources is going to be an issue. |
| tom66:
The Kintex-7 doesn't have a hard DDR3 controller! Spartan-6 and such do, but that was migrated over to the fabric in the later series of devices. I haven't prototyped it on a Kintex-7 but on an Artix-7, the MIG used 20% of the device. Admittedly that would have been a smaller 7A35T, but that is still 10% of logic used on the big Kintex device assuming it maps similarly - I don't know what the effect of moving to a 32-bit controller would be but I imagine it would further increase device utilisation. There is hardware acceleration for it on the FPGA fabric - the SERDES drivers for instance are optimised for DDR controllers - but it's still a 'soft IP' at heart. The biggest limitation of Zynq (when it comes to RAM) is in the standard speed grade the max DDR3 freq is 533MHz. You have to go up speed grade to get to 667MHz (or write PLL registers and overclock, but that is asking for trouble.) |
| asmi:
--- Quote from: tom66 on November 19, 2020, 09:01:57 pm ---IMO that wins over the 65k LUTs + no hardcore CPU + no DDR3 controller in the Kintex 70T -- and in my experience the MIG eats up easily 20% of the logic area for just a single channel DDR3 controller, I'm not convinced that would be a worthwhile trade off here. By the time you've implemented everything that the Zynq gives you "for free" (including 256KB of fast on-chip RAM) you're stepping up several grades of 'pure FPGA' to get there. --- End quote --- You missed the part that Kintex fabric is significantly faster than Atrix fabric (close to 50% in my experience, one design that barely closes at 180 MHz on Artix fabric, easily closes at 280 MHz on Kintex). And MIG in 160T part in FF package can implement 64bit 933MHz DDR3 interface, while Zynq only does 32bit 533 MHz. So not only you're getting 2 times wider data bus, you also get 400 MHz more frequency too. All it all, it's about 3.5x memory bandwidth. You also get 10G transceivers as opposed to 6G. That said, you can get both in Zynq-030 - it's got same 2 cores as your device, and you get 125K LUTs of fast Kintex fabric, can implement 64bit DDR3 *in addition* to what Zynq provides, and you get 4 10G transceivers. And it's also included in free version of Vivado. |
| asmi:
--- Quote from: tom66 on November 19, 2020, 09:33:17 pm ---I haven't prototyped it on a Kintex-7 but on an Artix-7, the MIG used 20% of the device. --- End quote --- MIG typically consumes 6 to 8k LUTs for DDR3 (quite a bit less for DDR2), and it obviously doesn't scale with device. Just for the hell of it I just created an absolute monster of controller with dual channel SODIMM controller for S100 device, and it took 24K LUTs. That is freaking 128 bit wide data bus! I personally think that K160T is the best midrange device - it can be used with free tools, it allows to implement a 64/72bit DDR3 interface via both discrete components and SODIMM module, and it can run it pretty fast - up to 933 MHz for a single-rank SODIMM module. You also get up to 8 10G transceivers either for talking to really high-end ADCs via JESD204B, or to connect to your main processing block, or both. |
| james_s:
--- Quote from: sb42 on November 19, 2020, 08:33:22 am --- Internet router: mass-market consumer product, cheap commodity hardware, Linux does everything. Oscilloscope: completely the opposite in every way? ;) The only way I see this happening would be for one of the A-brand manufacturers to come up with an open-platform scope that's explicitly designed to support third-party firmware, kind of like the WRT54GL of oscilloscopes. I suspect that the business case isn't very good, though. Manufacturers of inexpensive scopes iterate too quickly for reverse engineering to be practical. --- End quote --- Obviously there are large differences, but the benefit is the same. Open source firmware has the ability to be improved over time as deficiencies are corrected and new features added. The market of oscilloscopes is vastly smaller than that of consumer routers, but the market for high end DIY open source designed from scratch oscilloscopes is a tiny fraction of the already small market for oscilloscopes overall. The main thing that would appeal to me about a commercial scope is the packaging, it's a nice tidy form factor with nice buttons and knobs and everything in a professional molded housing, and all of the front end hardware is there, the place they are usually most lacking is in the software side of things. Ultimately I suppose this whole project is really only interesting to me from an academic standpoint, it's interesting to see the inner workings of a modern DSO and it's a truly impressive achievement, but if I'm going to spend $500+ I'd buy a TDS3000 and hack it to 500 MHz or a Siglent or Rigol and put up with potentially buggy firmware. Seems like this debate was also beat to death not too long ago, very few people are going to pay as much or more for an incomplete open source device than it costs to buy a ready made off the shelf instrument that is ready to use right out of the box just for the sake of it being open source. The main advantage of open source is cost, anyone can duplicate an open source project so competition drives cost down while innovation continues to result in incremental improvements to the design. If the cost is not significantly lower than a commercial product of similar performance then the market is very, very limited to that tiny segment of the population with the knowledge and desire to tinker and improve upon it. Most people don't care, most of the users of open source projects do not tinker with the source themselves even if they like the idea that they technically could if they wanted to. |
| Navigation |
| Message Index |
| Next page |
| Previous page |