AoE III price lowered another $10

We just had a 3-hour group session on possible DDS-based time-locked-loops. Hairy stuff. She kept up. Awesome for a kid like that.

Not, I think, as valuable as real electronic design.

I have three people here, and three available consultants, who want to type VHDL and do battle with Altera and Xilinx tools and gigabyte service packs and bugs. I don't want to program FPGAs either, any more. I just design architectures and let other people pound on the tools.

We have another woman here, working on her EE degree part-time, who is very good at FPGA design and Python programming. But she really doesn't like analog circuit design, too fuzzy or something, so I won't ask her to do that.

I'm letting her do what she wants to do, real electronic design, and we're teaching her what we know. I let her design a whole product, a gnarly waveform generator, which we're shipping now to a biggish aerospace firm. It's beautiful. Good stuff.

Then who does the imaginary electronic design? Or are you saying it's not complex at all?

We've had good luck with GA Tech and Rose Hulman students and grads.

It's a discussion group about electronic design, and you won't discuss electronic design. So why are you here?

FPGA design is one area where one needs to do it constantly to keep proficiency. The tools change so much that if you miss a few service packs, you're way behind the curve. That's most of the job; "pounding on the tools", as John says. It's even harder if you use more than one vendor.

She could do FPGA design quickly if she wanted to. Luckily, she doesn't want to.

Once you understand basic logic, 2s comp math, synchronous state machines, and a few tricks, FPGA design becomes an issue of learning and maintaining and doing battle with immensely complex and generally buggy tool sets, license servers, service packs, pin configuration files, timing constraints, test benching, battles for support, all that. Not a soldering iron or drill press in sight. Some people like that; some don't.

I don't think FPGA design is all that extreme that you have to do it continually. I have done it for years off and on and don't seem to have much trouble picking it up again after not designing any FPGAs for as much as a year.

I would guess that you are working with the Xilinx tools from the way you refer to it. I haven't used the Xilinx tools for at least 8 years if not longer and I understand they have dropped their in house XST in favor of a 3rd party tool, or at least they aren't maintaining it anymore.

Most of FPGA design is knowing what you want from the tools. Just as in any discipline, you need to be able to come up with the design in your mind. Then HDL and tool familiarity just helps you implement that design.

Just as JL seems to think it is a rare quality to appreciate and understand analog design, I find it is a rare quality to properly understand digital design. Anyone can bang on a kekboard... after all, look at all the keyboard monkeys who use LTspice to optimize a circuit rather than actually understand it. But understanding a digital circuit is no different than understanding an analog circuit. The other thing they have in common is that >90% of the time there is no point in optimizing, so any code monkey can get the job done.

This statement shows two things... that you are working with Xilinx tools and that you really don't know diddly squat about digital design. Or that maybe your designs just don't use very sophisticated digital designs because you don't know enough about it. Actually I think your long list of the "issues" of digital design shows you just aren't good at it and so the whole process is a struggle for you. "Test benching"??? Really? You see constructing a test bench in HDL to be a shortcoming of digital design?

I spent the most time on Xilinx tools but also Altera and Lattice. I haven't done much in the last three years and wouldn't think about applying for a job now.

Of course but it's not as easy as you pretend. The tools don't make it easy.

I don't see a big difference. Small problems are small in either domain. Big problems are just as big.

We just did one project where the FPGA guy (a consultant) burned most of a month trying to get an ARM processor (inside a ZYNQ) to talk reliably to the hardware through the Axibus. I mean, just reliably reading and writing FPGA registers from C code. Another story.

He's transitioning from ISE to Vivado or some such nonsense. We wanted to generate an ascii file full of FIR filter coefficients, and load them into a ROM (which is actually a RAM) at compile time. We never got that to work. We had to edit the coefficients themselves into the VHDL source.

If it's a new tool suite, how come it's as buggy as the old tool suite?

We prefer Altera, because the tools are better. But we did a couple of MicroZed projects, with the Xilinx ZYNQ chips, because the Altera SOCs weren't ready. The Xilinx projects were painful.

I respect, and do, digital design. We do all sorts of cool DSP and DDS and filtering stuff. Drawing the architecture is the fun part. Getting the FPGA tools to implement it is painful.

The ARM-Axibus-fabric thing was horrible. And Vivado doesn't respect the VHDL standards.

We prefer Altera but had to do two Xilinx designs recently. Dual-core ARM SoCs, embedded Linux, Ethernet and USB, massive signal processing and filtering, Is and Qs all over the place. I defined and architected the products, designed the schematic on one (delegated the other), coordinated the FPGA and Arm code at the detail level. I don't have time to lay out 8-layer boards, or write Linux apps and drivers, or battle Xilinx tools.

I do digital delay generators, waveform generators, DDSs and digital PLLs and all sorts of designs, at the block diagram and register and flipflop level. Then I hand it to an FPGA person to try to get the tools to actually build it. Designing digital logic is a distinct skill from driving the tools.

Tell me how you would do this:

or this

or this one (lots of trig and spinney things)

No, just another chore, necessary because people can't trust their own VHDL to be right, and because FPGAs are so hard to debug. Test benching takes about as much time as the actual design, sometimes more.

I hear that Rice turns out some good EEs too.

Colorado and Montana State both turn out a lot of excellent EEs--folks who do their own soldering and even their own algebra (the crowd gasps).

Central Florida cranks out a lot of good electrooptics folks, too.

Cheers

Phil Hobbs

You have to figure anything that can be made difficult will be difficult in something new like an internal interface between a complex CPU and the FPGA fabric.

I haven't worked with Vivado. Other synthesis I have worked with didn't seem to have problems with any of the code I've written in the last 15 years or so.

Are those the only issues you've had? Hard to condemn the entire process of designing with FPGAs based on a couple of tool problems. Your earlier post listed all sorts of stuff that just shouldn't be a problem. "immensely complex and generally buggy tool sets, license servers, service packs, pin configuration files, timing constraints, test benching, battles for support". The only thing in this list that is any different from analog design or is any sort of a real problem is timing constraints. I have always considered that to be a single point of failure as it is a one way process. You enter the constraints with no way to verify them. No good way to debug them either. You find out you have a timing problem after to deal with all the other bugs and the ones that remain change every time you make a change to track them down.

Otherwise I think you are just being whiny.

I don't claim to be the beginning and the end of FPGA design. I just don't find it hard to do. I think that is because I do the digital design in my head or with block diagrams and just use the tools to implement the picture. Not terribly different from working with wood except I can use version control.

Ask Xilinx. They are the source of your problems, not the concept of FPGA design. I'd also ask why you used the Zynq without checking the quality of the tools.

Lol! You are such a trip. Clearly you know very little about software design as well. Yes, design *verification* needs to be very detailed and well done to avoid problem that are much harder to debug on the bench. Software is the same way. Software design has been studied to death and the bottom line is the same mistakes are made over and over, which are mostly not spending enough time on the design specification, decomposition and planning for testing. They show time and time again that spending time to do it right gets a working design faster and cheaper.

If you don't spend as much time on coding the test bench as you did on your design, I can see why you don't like the results.

On Wed, 03 Jun 2015 14:55:38 -0400, rickman Gave us:

WAY better than any RPi.

On Wed, 03 Jun 2015 13:16:16 -0700, John Larkin Gave us:

Which proves you have no clue about how hard they are to make, much less how much weight your non-solution would add.