Xilinx has the Zynq and Intel/Altera has the Cyclone V.
Are there any others? Google was not much help. Lots of spurious hits.
I'm starting to develop FOSS Verilog for DSOs and it would be *very* helpful to have a 3rd platform as it is much easier to get the vendor to take ownership of a bug in their development tools if you can tell them that the code works on two other systems.
To start with I'm using a MicroZed and a DE10-Nano for my initial development and will switch to a Zybo Z7-20 when I start working on the display portion and need an HDMI output. At that time I'll get boards with HDMI output for the other platforms.
I started this some time ago, but got stalled buying T&M gear and other stuff. I modified the thread name and moved it to Projects. This will probably take 12-18 months to complete working on a retiree schedule and having to deal with multiple computers to satisfy software system requirement conflicts.
Do you need application processors, or microcontrollers?
In addition to the Cyclone V, Intel/Altera have the Arria V and Arria 10 with dual Cortex-A9 cores, and Stratix 10 with a quad-core Cortex-A53 CPU. Xilinx' Zynq UltraScale+ MPSoC and RFSoC also have Cortex-A53 CPUs.
Microchip/Microsemi's SmartFusion 2 have a Cortex-M3 MCU.
everyone (imporant) makes fpgas with arm processor cores now.
I'm looking for something from a 3rd vendor with their own tool chain. I didn't find anything from Lattice which surprised me. I need something on a par with the Zynq 7010/20.
As stated in the initial post, I have a MicroZed and a Zybo Z7-20. My DE10-Nano did not arrive today as I had hoped. It *should* have been in today's mail. But I need something comparable to those from a major vendor with a free tool chain such as the Quartus Lite edition.
You need a DS-5 license to develop on ARM with the Altera/Intel platforms. I think you can get away with it if you use embedded Linux on the SoC but I'm not sure.
The SmartFusion2 uses a much less powerful ARM core (Cortex M3, as previously stated) so it's not really a replacement for the Zynq. Also the license is only free for very small FPGAs (25K LEs).
AFAIK there aren't other producers of FPGAs with hard ARM cores.
it is much easier to get the vendor to take ownership of a bug in their development tools if you can tell them that the code works on two other systems.
I'm not sure I'd agree with that assumption. Far more likely, IMHO, is that a vendor will take ownership of a bug in their tools if the organisation reporting the bug places orders with a value in excess of $1M / year.
If you're developing some FOSS then that's great, but please, don't invest the time and effort developing three FPGAs. If you have three FPGAs' worth of resources, then spend them instead developing one FPGA, documenting it thoroughly, and providing responsive and capable support to anyone who wants to make use of it.
I'm looking for something from a 3rd vendor with their own tool chain. I didn't find anything from Lattice which surprised me. I need something on a par with the Zynq 7010/20.
How about Microsemi (formerly Actel) FPGA's. Their SmartFusion / SmartFusion2 SoC devices have ARM Cortex M3's and various other peripherals. Their Libero toolchain is available in a free version, I think the main difference between the free and paid version is relating to the ModelSim version and also the available Synopsys synthesis tools.
You need a DS-5 license to develop on ARM with the Altera/Intel platforms.
You need a DS-5 license to use DS-5. It is not a requirement. User-level Linux application debugging is free with DS-5. I use the Cyclone V SoCFPGA at work, and we develop the Linux software using Yocto and its SDK. Those who like using IDEs use the SDK with either vanilla Eclipse, or CLion from JetBrains.
I'm looking for something from a 3rd vendor with their own tool chain.
There are not many FPGA vendors. There are even fewer in the high-end market segment that would embed an applications processor.
it is much easier to get the vendor to take ownership of a bug in their development tools if you can tell them that the code works on two other systems.
I'm not sure I'd agree with that assumption. Far more likely, IMHO, is that a vendor will take ownership of a bug in their tools if the organisation reporting the bug places orders with a value in excess of $1M / year.
If you're developing some FOSS then that's great, but please, don't invest the time and effort developing three FPGAs. If you have three FPGAs' worth of resources, then spend them instead developing one FPGA, documenting it thoroughly, and providing responsive and capable support to anyone who wants to make use of it.
I'm going to be writing Verilog code. I want it to be as portable as possible. I know from personal experience that testing code on multiple platforms *as you write it* identifies issues with the compilers and the language standards. Sequential ports *are a lot more work*. If Verilog is not portable across vendors I want to know it at the start, not a year later when an OEM chooses a different chip for their new design.
In this case, I also need to be aware of hardware variations in the same way you have to if you're working on the CPU intensive portion of a seismic processing algorithm where *everything* matters down to the order and stride of your array accesses.
My goal is to develop FOSS IP for T&M gear so that I'm not dependent upon the OEM to fix things or add features. I want it to be usable on anything put on the market. There have been numerous rather pointless threads speculating about FOSS FW for DSOs. Eventually I came to realize the problem was most people did not understand complex DSP flows, so it looked much harder than it is.
I spent many years writing and maintaining seismic processing codes. For me *everything* a DSO can do is trivial DSP 101 stuff. I've worked on 2 commercial seismic processing systems and a pair of closely related academic systems. There are really only two ways to go about it, either in single trace or multiple trace chunks. Each has to do the same things to the data so each has some fiddle required to handle the other option.
I'm going to be writing Verilog code. I want it to be as portable as possible. I know from personal experience that testing code on multiple platforms *as you write it* identifies issues with the compilers and the language standards. Sequential ports *are a lot more work*. If Verilog is not portable across vendors I want to know it at the start, not a year later when an OEM chooses a different chip for their new design.
Not sure about verilog but VHDL is completely portable between vendors; I started out using altera FPGAs, and had written a large library of vhdl modules targeting altera only with no consideration for portability. Later when I switched to xilinx I found that all my old code just worked.
I'm going to be writing Verilog code. I want it to be as portable as possible. I know from personal experience that testing code on multiple platforms *as you write it* identifies issues with the compilers and the language standards. Sequential ports *are a lot more work*. If Verilog is not portable across vendors I want to know it at the start, not a year later when an OEM chooses a different chip for their new design.
Not sure about verilog but VHDL is completely portable between vendors; I started out using altera FPGAs, and had written a large library of vhdl modules targeting altera only with no consideration for portability. Later when I switched to xilinx I found that all my old code just worked.
I agree. Just start with Xilinx and go from there. Don't infer basic building blocks (for example use an array as memory with the added bonus that the synthesizer will choose the best type of memory). IMHO VHDL also offers more flexibility to make designs scalable/portable compared to Verilog.
If Verilog is not portable across vendors I want to know it at the start, not a year later when an OEM chooses a different chip for their new design.
Given that the ARM cores themselves are written, tested and implemented in Verilog (and SystemVerilog), it can be very portable.
You *really* should focus on one FPGA and supporting it well. If this is your 1st go on a high end FPGA, you really need to think about your development strategy. Trying to target several FPGA platforms is going to lead to disappointment. Just look at other FOSS FPGA platforms (Red Pitaya). they have a hard enough time supporting *one* platform.
While it is true you can write Verilog that can synthesize under different toolchains, there are lots of features in the different vendors parts that cannot be inferred with generic HDL.
My experience over many FPGA projects (especially on the high end) is that purely generic HDL can be portable but is also not optimal. I completed FPGA project which was doing imaging processing for a space application. We were able to get a 5x improvement in processing efficiency by *thinking* about how the algorithm would map to available resources and directly instantiating hardware in the FPGA. Generic HDL can certainly get things to work but falls apart quickly when you are trying to push the speeds and density.
I'm starting to develop FOSS Verilog for DSOs and it would be *very* helpful to have a 3rd platform as it is much easier to get the vendor to take ownership of a bug in their development tools if you can tell them that the code works on two other systems.
There are only 2 players in the high end space: Xilinx and Altera. They are not going to care about your FOSS project and fixing bugs. Until you get to 6 or 7 figures in a purchase order, you have no leverage. That is just a reality.
If Verilog is not portable across vendors I want to know it at the start, not a year later when an OEM chooses a different chip for their new design.
Given that the ARM cores themselves are written, tested and implemented in Verilog (and SystemVerilog), it can be very portable.
You are forgetting that ARM cores are implemented in silicon (chips) and that is a whole different ball game compared to dealing with FPGAs. Apples and oranges.
If there are only two, they will just say theirs is right and the other's is wrong.
I discovered the benefit of testing simultaneously on multiple platforms during a 500,000 line port from VMS to Unix. That code had fewer than a dozen bugs reported in the first release and it went down from there. Because we built tests cases and ran them on multiple platforms as we wrote the code we quickly learned what things to avoid. That code was in service for 12-16 years and completely unsupported for 4-6 years. They only pulled the plug when it simply became obsolete.
In seismic processing a major operation involves summing 10**5-6 samples into *each* of 10**13-15 samples for the *simplest and cheapest* method. Doing this takes 10**4 or more cores running for 7-10 days. The current state of the art algorithms are an order of magnitude more CPU intensive.
A friend of mine spent over $250K porting a state of the art code to both FPGAs and GPUs. There was not sufficient performance improvement to justify the cost of completing either port and deploying it. That's how well tuned to the Intel architecture the existing code is.
When I wrote code 20 years ago for the simplest algorithm I chose a DEC Alpha for the floating point performance. The inner loop ran 10% faster if I used explicit temporary variables and used a stride of 2 for the loop. I read Alpha documentation for weeks for that project. That code was not used by the Intel version.
When developing such code you take into consideration instruction issue, pipeline latencies, cache organization, etc. I have 4 editions of "Computer Architecture: A Quantitative Approach" by Patterson and Hennessy. I've read the first 3 cover to cover. I've not read the 4th because I've not had an HPC code to work on since I bought it. So all I did was a quick skim to look for anything new.
I would not even consider developing FPGA code that did not take into account the particulars of the target hardware. That will get isolated by #ifdef and the code run through the C preprocessor. But a lot of it will be generic. This is where profiling execution comes into play. You only optimize the stuff that matters.
I looked at both Verilog and VHDL. I like the syntax of Verilog much better.
Anyway, thanks for confirming that I hadn't missed another chip vendor. I'll just have to live with two instead of three. And hopefully my DE10-Nano will arrive today.
If there are only two, they will just say theirs is right and the other's is wrong.
I don't get why you are worried about this at all. These tools have been on the market for decades with hundreds of thousands of users. If there is a problem you are not the first to run into it and the answer can always be found through Google.
I would not even consider developing FPGA code that did not take into account the particulars of the target hardware.
That is the wrong way of going at it. Just like a C compiler optimises for the platform particulars a synthesizer does exactly the same. It doesn't hurt to read the synthesis manual to know how certain low level building blocks are instantiated but try to avoid instantiating the low-level building blocks directly. You can declare an array in VHDL in one line. Instantiating a low level memory block takes much more work AND it may not even be as efficient as you might think.
I looked at both Verilog and VHDL. I like the syntax of Verilog much better.
VHDL has all the good stuff like records (structs) and strong typing. Using records alone to concatenate related signals into one saves a huge amount of typing.
Looking at an FPGA design like a functional problem works better in a higher level language. Now people will come and chime in saying that they can get maximum speed / minimum size from yadda yadda yadda but the fact is that just like C/C++ programs 99% of an FPGA design isn't speed or resource sensitive. The most precious thing is development time. You don't want to write an application like a modern full featured web browser (like Firefox) in assembler.
By the way: I'm missing simulation in your requerements.
AFAIK VHDL also provides better functionality to write test benches (signal stimulus / verification) much more easily compared to Verilog. I only have experience in VHDL, but at least there it's almost too easy to create a behavioral test bench using the non-synthesizable constructs.
VHDL has its own stupid verbose things like the requirement to write super_long_(type_casts(everywhere))), and for example, the inability to index such a type cast, leading to a three-liner including a temporary variable to do a trivial thing like comparing a single bit.
... but all languages have some nuisance features like this.
VHDL has its own stupid verbose things like the requirement to write super_long_(type_casts(everywhere))), and for example, the inability to index such a type cast, leading to a three-liner including a temporary variable to do a trivial thing like comparing a single bit.
That is only if you make all multi-bit vectors which are actually numbers std_logic_vector. Use the numeric library and use a numeric type for every signal which represents a number. That saves a whole lot of typing.
You are forgetting that ARM cores are implemented in silicon (chips) and that is a whole different ball game compared to dealing with FPGAs. Apples and oranges.
ARM uses several different FPGA platforms for validation. Several semiconductor vendors (i.e. NXP, TI) do the 1st verification of their chips on an FPGA. The code is very portable. Even the new RISC-V is in Verilog for FPGA implementation.
Both HDL's can achieve the same goal. Much of it comes down to personal preference.
AFAIK VHDL also provides better functionality to write test benches (signal stimulus / verification) much more easily compared to Verilog. I only have experience in VHDL, but at least there it's almost too easy to create a behavioral test bench using the non-synthesizable constructs.
That is only true if you still live in the past century. Because in this century SystemVerilog is light years ahead when it comes to verification. VDHL is a stone age tool in comparison.
AFAIK VHDL also provides better functionality to write test benches (signal stimulus / verification) much more easily compared to Verilog. I only have experience in VHDL, but at least there it's almost too easy to create a behavioral test bench using the non-synthesizable constructs.
That is only true if you still live in the past century. Because in this century SystemVerilog is light years ahead when it comes to verification. VDHL is a stone age tool in comparison.
Still.. how well is SystemVerilog supported while Xilinx Vivado has trouble with some VHDL constructs? To me it also seems like Verilog with a whole bunch of stuff bolted onto it. Keeping the old problems AND adding new ones.
Not sure about verilog but VHDL is completely portable between vendors; I started out using altera FPGAs, and had written a large library of vhdl modules targeting altera only with no consideration for portability. Later when I switched to xilinx I found that all my old code just worked.
It depends on what you're doing. If you just write general HDL (either VHDL or Verilog), it is very portable. However, if you work on something very fast, or IO related (involving clocking schemes, SERDES, calibration etc.), or use something vendor-specific (such as interfacing PC through built-in JTAG), I am not sure it is ever possible to make the code portable.
VHDL has its own stupid verbose things like the requirement to write super_long_(type_casts(everywhere))), and for example, the inability to index such a type cast, leading to a three-liner including a temporary variable to do a trivial thing like comparing a single bit.
That is only if you make all multi-bit vectors which are actually numbers std_logic_vector. Use the numeric library and use a numeric type for every signal which represents a number. That saves a whole lot of typing.
That's exactly what I did. The problem I faced was a style policy forbidding the usage of anything else than std_logic and std_logic_vectors in entity ports.
My solution to that, after some nagging, was finally to simply disregard the policy. Others started to do the same so it worked well. Fight the power
You still can't completely avoid these casts, and the totally illogical naming - some have to_ prefix, other do not, for example - of these library features is daunting for beginners, as I oversaw while giving classes.
AFAIK VHDL also provides better functionality to write test benches (signal stimulus / verification) much more easily compared to Verilog. I only have experience in VHDL, but at least there it's almost too easy to create a behavioral test bench using the non-synthesizable constructs.
That is only true if you still live in the past century. Because in this century SystemVerilog is light years ahead when it comes to verification. VDHL is a stone age tool in comparison.
Regarding FPGA, digital ASIC and design capture/verification, I've been under the rock for... about 6 years? ... but to talk about "past century" is definitely not true. While looking at this in around 2010 last time IIRC, SystemVerilog wasn't very widely used (if at all) in the real world yet; but was touted as the next big thing. We did a lot of academic work (mostly useless papers and such) around SystemVerilog and SystemC, anyway, but saw little practical use. I guess the game has changed, now?
Still, I see the simplicity of building a 10-line VHDL testbench using the single unified design language appealing; as long as unit size is small. For complex systems, this of course won't scale up well for complete system-level simulation.
But VHDL is a surprisingly capable language with surprisingly little "feature bloat". It's a reasonable task to learn all the VHDL features available, and most will be very useful (and offer more than Verilog). Syntax is a bit verbose though, especially if you come from C background.
Still.. how well is SystemVerilog supported while Xilinx Vivado has trouble with some VHDL constructs?
Pretty good. See latest UG900 and UG901 for details - most features are supported. It greatly improved in last few releases once Xilinx started shipping their own IPs entirely developed in SV.
To me it also seems like Verilog with a whole bunch of stuff bolted onto it. Keeping the old problems AND adding new ones.
That just tells me that you didn't bother learning anything about it, while still having "an opinion"
SV fixed all major annoyances of "classic" Verilog (like that reg/wire business, lack of support for enums), plus it added a whole bunch of new features, some of which are entire game-changers (like support for interfaces and ports in
synthesizable code, this makes developing modules with AXI links so much easier as you no longer have to copy-paste a million of signals that belong to AXI bus). The only real bummer is lack of IP integrator support, but it only requires that top level module is written using Verilog/VHDL, while all internal modules can be in SV.