Author Topic: FPGAs with embedded ARM cores, who makes them?  (Read 5133 times)

0 Members and 1 Guest are viewing this topic.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3363
  • Country: ca
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #75 on: August 05, 2018, 07:10:25 pm »
Reading everything so far, I personally would choose a CycloneV or Xilinx equivilant low end dev board with embedded Arm and hopefully 2 banks of DRAM, 1 dedicated for ARM software and another for high speed sampling with as a plug, a HDMI/VGA output.  Start out with a cheap home made 500MSPS converter as these dev boards will struggle to interface any faster, they might even limit you a bit slower.

I know this will have an embarrassing cost below 800$ total, even if you need to make you own custom ADC daughter board, but the code you test and develop will be identical to your super fast final high end final product.  All the tricks you will need to speed up the CycloneV to deal with a 500MSPS ADC with it's 400-600Mhz DDR3 ram and real time processing will be equivilant to when you upgrade to an Altera Arria FPGA to handle to speed of the DDR3/4 1.3GHZ ram and 2-3GSPS ADC.  Your development and learning cure will be the same and with a compiled project, you will be better suited in per-compiling and being able to select whether you will need a Arria, or Stratix FPGA from Altera (or Xilinx equivilant) to make the jump into multi-GHz sampling.

I am not sure of the level of capability in Xilinx's IDE, but I would personally use 'System Verilog' instead of 'Verilog' since at the time when I started my video scaler, System Verilog automatically tracked and handled mixed unsigned and signed registers for the component color processing math I required when feeding Altera's DSP blocks with less headache than the regular old Verilog.  Things may have changed since this was 5 years ago.
__________
BrianHG.
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 2677
  • Country: us
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #76 on: August 05, 2018, 08:02:34 pm »
I currently have an Avnet MicroZed, Digilent Zybo Z7-20, BeagleBoard X15, Terasic DE10-Nano and a Zynq 7010 based Instek GDS-2072E DSO with a 500/1000 MSa/S dual channel ADC.  So I think I'm pretty well equipped for the initial work.  I had the good fortune to get the Instek for $244 delivered from Amazon.

My current plan is to work through the MicroZed and DE10-Nano tutorials, doing each one on both platforms.  That will give me a good idea of the quality of the tools and a basic sense of how much portability is possible.

While a full feature synthesis and fitting package is clearly beyond the ability of one person, I have used lex and yacc for professional work, am familiar with optimization codes and device level physics.  So for the very narrow range of tasks I'm pursuing, writing my own is not impossible.  Just far more work than I should like.

This started as an attempt to escape from bad Chinese FW.  Then I tried to buy my way out and bought a $20K DSO at 1/2 price which I returned and then got a week or so of demo time with another A list DSO.  Much to my dismay and horror, even $20K would not buy me a DSO which functioned properly. After what I've seen, I don't think any sum would get me a sensible and bug free instrument.

Having written large, complex pieces of software which were bug free, I don't think buggy products are inevitable.  As I wrote in a 4 page memo I sent to the 2nd A list OEM.  "Bugs in software may be inevitable, but shipping them to customers is unprofessional."

I shudder at the thought of your having read this whole thread.

If you know of good discussions of software engineering in the context of HDLs I'd be very grateful if you would post or send me  links.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #77 on: August 05, 2018, 08:56:43 pm »
1.  Enable input and enable output, where the enable is a DFF with the same pipe size as the function allowing the data flow to go on and off at any point, with an embedded parameter size configuration control.

We have apparently invented the same wheel.

-a
 
The following users thanked this post: BrianHG

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1291
  • Country: us
  • Yes, I do this for a living
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #78 on: August 05, 2018, 09:17:50 pm »
Having written large, complex pieces of software which were bug free, I don't think buggy products are inevitable.  As I wrote in a 4 page memo I sent to the 2nd A list OEM.  "Bugs in software may be inevitable, but shipping them to customers is unprofessional."

That's true for any product, I think.

But let's step back even further. The previous discussion was all about synthesizing logic and fitting it into the resources available in the target device. That process, which can seem unwieldy because of the tools, is actually straightforward.

There is a significant assumption about it, though. The assumption is that the logic you wish to implement in your chip is functionally correct. That is, if you take a design which is functionally correct and you synthesize it according to the rules and you constrain it properly and you meet the constraints, it will work.

And the truth is that verifying that your logic design is functionally correct is hard. Simulation is part of the verification process. Writing a comprehensive test bench is not trivial, especially when your FPGA talks to a peripheral as a data source or sink. (This means you need to obtain, or more likely write, bus-functional models of the things you connect to your FPGA, and then you have to verify that the models are correct!) The test bench should do more than generate a clock and reset, and staring at waveform displays isn't verification. It just shows you what is happening for a given set of conditions, and doesn't tell you what it should be doing for that given set of conditions.

A test bench should apply test vectors and verify that the output is what is expected. Yes, it should be obvious, but it must be stated -- you have to know what you should get out of the circuit for a given input!

Now there are a bunch of people on this forum who are manly men and refuse to do any kind of simulation. Their design skills are clearly impeccable and they don't make even the smallest of typos. Or, they say, "I'll use ChipScope, it's faster than writing a test bench." Except when a place-and-route cycle takes an hour, and if you forget to include a signal to monitor, or make some other omission, then it's another hour wasted. Or, sometimes the case might be that the debugger core makes the design not meet timing, and then you can't trust its output.

You can't do serious FPGA design and development without understanding how to functionally verify a design.

Quote
If you know of good discussions of software engineering in the context of HDLs I'd be very grateful if you would post or send me  links.

I have not seen any. Hell, given that FPGA design is all text-based design entry these days, you would think that every professional FPGA designer has embraced source-code control for their designs. But you would be wrong.
 
The following users thanked this post: Siwastaja

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 3363
  • Country: ca
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #79 on: August 05, 2018, 10:00:51 pm »
Now there are a bunch of people on this forum who are manly men and refuse to do any kind of simulation. Their design skills are clearly impeccable and they don't make even the smallest of typos. Or, they say, "I'll use ChipScope, it's faster than writing a test bench." Except when a place-and-route cycle takes an hour, and if you forget to include a signal to monitor, or make some other omission, then it's another hour wasted. Or, sometimes the case might be that the debugger core makes the design not meet timing, and then you can't trust its output.
For major projects, like my video scaler, I have each function in it's own project with it's own test bench simulation.  I simulate and exhaust all the possibilities for each individual function or combination of some small functions together.

Next level up, I have my main project which uses each sub function project wired together, basically a top hierarchy, and simulate that one as far as I can.  I am bound by certain limitations here at this level since it can take hundreds of millions of clock cycles just to boot everything up to a synced functional state.  The PC would take forever to simulate this, or, at least 5-6 years ago, with a 2 core cpu, this was the case at the time working with a freeware web version of Quartus.

Without at least these 2 to 3 levels of simulation, what I have achieved would be impossible.
« Last Edit: August 05, 2018, 10:02:27 pm by BrianHG »
__________
BrianHG.
 

Offline rhb

  • Super Contributor
  • ***
  • Posts: 2677
  • Country: us
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #80 on: August 05, 2018, 10:09:16 pm »
ROFL!!!

Bassman59 and BrianHG, you make my heart glad.  I'm not the only one who understands the problem and how to address it.

The test bench has to include every case you can think of that might arise.  And writing good test cases is far more art than science.  As a summer intern at a major oil company, one of the scientists was having problems with a 3D FFT on a parallel machine (Intel i386 Hypercube).  He mentioned it to me.  I told him to run two test cases. an input which was a central spike and an input which was all ones.  He found the bug in 15 minutes.  I was quite astounded he didn't know to do this.

But, no, I would not be surprised that the majority of FPGA designers behaved like the majority of programmers and did not use version control. In fact, that is precisely why I think I can do better than the norm.

If it's not a "kick the tires" exercise, the first thing I do on a new system is install RCS to manage the administration files.  I have a system with swappable drives and over two dozen disks which I use to test things. Twenty years ago my ISP  starting bouncing all my outgoing mail back.  I called support ( a friend owned the company).  The support guy said it must be a mistake in my sendmail.cf.  To which I responded, "My sendmail.cf has not been changed since "date" and the RCS log says that change was due to a change of yours on "date".  I never mentioned that the owner was someone I knew.  But the support guy got the message.  I could prove that it was not a mistake on my part.  I forget what they had munged, but they did find and fix it.
 

Online hamster_nz

  • Super Contributor
  • ***
  • Posts: 2135
  • Country: nz
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #81 on: August 05, 2018, 10:23:30 pm »
ROFL!!!The test bench has to include every case you can think of that might arise.  And writing good test cases is far more art than science. 

Have you tried any formal verification?

You define how your component has to perform and the toolset tells you if your design meets those requirements.

See Clifford Wolf's Slides at http://www.clifford.at/papers/2016/yosys-synth-formal/slides.pdf

Quote
Formal verification uses modern techniques (SAT/SMT
solvers, BDDs, etc.) to prove correctness by essentially doing
an exhaustive search through the entire possible input space.

It is pretty good at actually proving that RTL works as required... I've dabbled in it only a bit.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline RoGeorge

  • Super Contributor
  • ***
  • Posts: 1783
  • Country: ro
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #82 on: August 05, 2018, 10:57:25 pm »
I would not be surprised that the majority of FPGA designers behaved like the majority of programmers and did not use version control. In fact, that is precisely why I think I can do better than the norm.

Prepare to be surprised.
Professional developers, as far as I seen, do use version control, testbenches, simulation, boilerplates, automated and manual testing, continuous integration, and more.

It's obvious that an open source digital oscilloscope will cost more, both in hardware and effort compared to on the shelf scopes, but it might come with great advantages in the long run. That is why I would like to see such a project, too, but there might be a reason for the lack of any such project yet. IMO, trying to make it compatible with many FPGA manufacturers is unrealistic. I will stick with one vendor, at least for the beginning.

Anyway, before throwing big $$$ for high speed devboards, I will suggest starting small, with a modest ADC + RAM + Zynq, just to identify where the major effort sinks are, and to see if people are willing to crowd around the project or not.

From there, it may fly or not, wish all the best to the project.

Offline rhb

  • Super Contributor
  • ***
  • Posts: 2677
  • Country: us
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #83 on: August 06, 2018, 12:21:52 am »
If you know of good discussions of software engineering in the context of HDLs I'd be very grateful if you would post or send me  links.

I have not seen any. Hell, given that FPGA design is all text-based design entry these days, you would think that every professional FPGA designer has embraced source-code control for their designs. But you would be wrong.


Bassman59 has experience with FPGA developers.  I just have experience with software developers.  Most of whom I have found severely underwhelming.

I am not considering developing an open source DSO.  Never have.  Except for bespoke high performance instruments made up from eval boards it's not economic. 

My goal is  FOSS FW for COTS gear.  But i know from experience that taking into account a more general set of requirements typically pays off in the end.  Even if you don't implement any of it.  Understanding the issues can keep you from making serious design mistakes.

How will I learn what the differences between vendors are except by doing exactly the same thing on multiple systems?  I'm really tired of the "pick one and just do that" BS.  In this case I have a 50-50 chance of picking the worst one.
 

Offline daveshah

  • Supporter
  • ****
  • Posts: 356
  • Country: at
    • Projects
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #84 on: August 06, 2018, 06:19:04 am »
If you really want to make sure your design is good, you could have a look at Yosys and SymbiYosys, a FOSS formal verification suite for Verilog, that can prove your design is correct for all cases.

I would recommend the ZipCPU blog as an introduction to using Yosys for formal verification.
 
The following users thanked this post: rhb

Offline carl0s

  • Supporter
  • ****
  • Posts: 222
  • Country: gb
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #85 on: August 06, 2018, 07:52:34 pm »
FPGA Hell. Jesus. I'll pray you stay out of there.

I'm in RGB TFT Hell. It should be easy, but I'm exhausted.
--
Carl
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4348
  • Country: ch
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #86 on: August 06, 2018, 09:16:39 pm »
Yup, a lot of my colleagues use git for both C/C++, Ada and vhdl  :popcorn:
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 4348
  • Country: ch
Re: FPGAs with embedded ARM cores, who makes them?
« Reply #87 on: August 06, 2018, 09:27:52 pm »
Quote
gave me a strong confidence when making the change that the result would still work.

want new features?

open a branch (on git)
commit everything
test it on your workbench with test-cases made on stubbed modules, to see if what you have modified has changed/compromised the behavior of some module, and don't forget to simulate the whole design for system integration to check that everything is globally OK

(all of this can be automatically checked, even by Makefile)

does the result still work?
yes: comment the commit as step-milestone, and go ahead
no: revert to the previous commit

it has become the common practice nowadays, especially for the team working over the internet :-//
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf