Overcoming BGA FPGA, perhaps...

[gnuarm]

The fact there's also a lot of HDL examples of various sizes online helps a lot. I didn't design the AES block or the polynomial multiplier (or the sd-card controller but I've yet to get that one to work...), I just used what was publicly available.

Polynomial multiplier... is that a polynomial division such as in a CRC calculation?  The hard part of CRCs would be figuring out all the bit order and complementing that has to happen.  There's 2^N combinations and often you get it right on the last one.  Exhaustive tree search is a bitch.

[dolbeau]

Polynomial multiplier... is that a polynomial division such as in a CRC calculation?

No, as in GCM mode for AES; There's online code from a book that includes a lot of examples: Hardware Implementation of Finite-Field Arithmetic.

I currently use a full 128bits multiplier with the proper modulo for GCM; combinatorial code works fine single-cycle for me... so I need to change it, as it's much faster than the bus it's hooked up to and takes a *lot* of space in the FPGA :-)

[gnuarm]

Ok, but the same sort of thing where "multiply" defined by an XOR operation and no carry between bits, no?

[dolbeau]

Ok, but the same sort of thing where "multiply" defined by an XOR operation and no carry between bits, no?

Same sort of thing; _addition_ is XOR - multiplication is much more complicated (unoptimized version). So complicated that modern CPU have dedicated instructions to accelerate them (e.g. pclmulqdq in SSE, various PMUL in Arm NEON).

[gnuarm]

Ok, but the same sort of thing where "multiply" defined by an XOR operation and no carry between bits, no?

Same sort of thing; _addition_ is XOR - multiplication is much more complicated (unoptimized version). So complicated that modern CPU have dedicated instructions to accelerate them (e.g. pclmulqdq in SSE, various PMUL in Arm NEON).

Conventional addition is XOR.  Polynomial division in finite fields is XOR, such as in CRC calculations.

[Sal Ammoniac]

Yea, I also think this way. What is ironic is that our brain is essentially a big biological FPGA, meaning massive-parallel processing unit. It's just doing many things at once goes against our nature because we only have so many hands, eyes and feet so we can't really multitask in a physical sense

Programming an MCU is like playing a wind instrument: one note at a time. With an FPGA, it's more like playing an organ where you can play ten notes simultaneously with your fingers and additional notes with your two feet.

[gnuarm]

Yea, I also think this way. What is ironic is that our brain is essentially a big biological FPGA, meaning massive-parallel processing unit. It's just doing many things at once goes against our nature because we only have so many hands, eyes and feet so we can't really multitask in a physical sense

Programming an MCU is like playing a wind instrument: one note at a time. With an FPGA, it's more like playing an organ where you can play ten notes simultaneously with your fingers and additional notes with your two feet.

That makes it sound like it is hard to do.  I'd say it is more like a one man band compared to a symphony.  The one man band is working very hard to play all the instruments and get them to sound good together.  It takes practice and skill and the result is often just barely good enough. 

A symphony is many instruments being played truly simultaneously allowing music to be created that is so rich it is hard to even imagine until it is heard.

[Sal Ammoniac]

That makes it sound like it is hard to do.

That's because it is. An organ is hard to play well. You're playing three lines of music simultaneously in two different clefs and each may have a different rhythm and you often need to change stops while playing.

[gnuarm]

That makes it sound like it is hard to do.

That's because it is. An organ is hard to play well. You're playing three lines of music simultaneously in two different clefs and each may have a different rhythm and you often need to change stops while playing.

That's why it is a poor analogy to programming in HDL.

In many ways programming parallel tasks in HDL is like using a Ronco Rotisserie, "Set it and forget it!"  Being a part of the language means it doesn't require much thought to use.

A <= B or C;

D <= E and F; 

There, two parallel tasks.  Wait, here's a third.

G <= A xor D;

See, not at all like playing an organ.  :-)

[NorthGuy]

These are bizarre analogies. You're not playing anything. You build a program which then "plays" on your device, as a music would play on a mechanical piano. With FPGA, you build the program by interconnecting logic elements. With MCU, you build the program by filling memory with executable instructions and initial data.

[Sal Ammoniac]

See, not at all like playing an organ.  :-)

That's because you chose three extremely simple operations. Real-world FGPA applications often have many complex modules interacting in complex ways.

[asmi]

These are bizarre analogies.

This is what happens when you push analogies a bit too far.

[gnuarm]

See, not at all like playing an organ.  :-)

That's because you chose three extremely simple operations. Real-world FGPA applications often have many complex modules interacting in complex ways.

That is the complexity of your design, not a complexity of the tool.  No tool is going to make a complex problem simple.  The best you can hope for is that it doesn't add any complexity which is what FPGAs do.  They let you implement your design without adding unneeded complexity. 

Implement your complex problem in sequential software and now you have to deal with the complexities of real time multitasking with prioritized interrupts, possibly on multiple processors. 

Do you know what they call "real time multitasking with prioritized interrupts, possibly on multiple processors" in FPGAs?  Programming. 

[Bassman59]

See, not at all like playing an organ.  :-)

That's because you chose three extremely simple operations. Real-world FGPA applications often have many complex modules interacting in complex ways.

Truth.

I think it's worth remembering that FPGA design is digital logic circuit design and it's nothing more than clever packaging of what we used to do in boards full of 74xx TTL or 4000-series CMOS logic chips. The "code" we write is in a hardware description language because it describes what the logic must do. We don't do FPGA design in a "programming language" because we are not programming the devices. (Programming in this context means "loading configuration data into non-volatile storage.")

Microprocessors are sequential-execution machines that ultimately do one thing at a time, and the languages used in programming are designed with that paradigm in mind.

YES, we know there are people trying to do "FPGA design in C" (so-called "high-level synthesis"). And YES, there are people who are trying to design or extend sequential-execution processor programming languages for parallel tasks.

Look at it this way:

A processor is just one example of digital logic circuit design. That's why we can implement a processor in an FPGA. (We could do it in MSI logic like TTL or 4000-series CMOS. We could do it in discrete logic with transistors. Or vacuum tubes.)

But we cannot implement an FPGA with a processor.

[glenenglish]

BGAs are super easy and super reliable.
They are SOOO easy to get right, as long as you have enough heat, and you only get ONE chance when you drop them on the board.

Xilinx make some 196 ball Spartan7s with 1mm pitch. These can be fabbed with el-cheapo PCB on say a 6 layer.
1mm  self solder paste stencilling is a doddle.

if you put the planes all in the top 3 layers and have a super thin PCB, say 0.1mm prepreg, you can get away without bottom side caps.....(plane capacitance doing the work)

Also, the 0.5mm Spartan7 - look at the footprint- all the busy stuff is around the edge actually quite easy to route out without crazy PCB tech- but your stencil paste work must be good !

Spartan7 is good bang for your buck and 7S25 and higher have fast multi channel differential input ADCs.

Now, you can go Lattice. Lattice is a good company, and their devices are excellent, and the documentation is good. But the tools are not as polished. If the design is simple, Lattice in QFN might be your best bet. But honestly, a 0.5mm QFN and a 0.8mm BGA are easy peasy- except that  the QFN might be easier to route on on a low tech PCB.

Glen.
(disclaimer : Xilinx Alliance Partner)