Flavia: the Free Logic Array


johnbeetem

Recommended Posts

Flavia, the Free Logic Array, is a programmable device intended primarily as a teaching tool for FPGAs and CPLDs.  Unlike every commercial device I'm aware of, Flavia's tool suite is free-as-in-liberty open-source software (FLOSS).  This means it can run on platforms other than x86 PCs, including Raspberry Pi (tested) and BeagleBoard/Bone (not fully tested yet).

Flavia is a "CPLD in an FPGA", which uses FPGA look-up tables (LUTs) to implement both logic and routing.  Since Xilinx documents ways to find the locations of your LUTs and flip-flops in their otherwise undocumented bitstreams, it's possible to program those LUTs to make a reasonably nice CPLD that can be programmed using FLOSS tools.

Flavia's first implementation uses the Papilio One 250K as its underlying FPGA.  The 250K Spartan-3E FPGA has enough logic resources to make a useful CPLD and the FT2232D provides an easy programming interface for Flavia's software.

If you're interested, take a look at my 'blog at element14, which has links to all the software and documentation.



This post has been promoted to an article
Link to comment
Share on other sites

I assume that the performance is about 1/5th or 1/10th of a raw FPGA (e.g. maybe up to 10 MHz or so?) - I'm definately going to have a look.

 

Thank you for the compliments!

 

I haven't checked performance.  Your estimates sound reasonable.  Today's answer to "how fast is Flavia?" is "if you need performance, use the vendor tools" :)

Link to comment
Share on other sites

>> Since Xilinx documents ways to find the locations of your LUTs and flip-flops

 

just a thought: It seems you're aiming for "free" software on one side, but vendor-specific technology on the other (i.e. LUT capabilities are by no means standardized even between Xilinx generations, for example).

Wouldn't it make more sense to draw the line higher, at the level of generic / portable / inferable code? That is, code in a way that isn't tied to one specific vendor.

For learning, looking up from the (vendor-dependent) hardware level is IMHO the wrong way to start nowadays, if the goal is to get the student to a level where FPGAs start to make any practical sense as a solution to real-world problems.

For purely synchronous logic, you don't need to know anything about the low-level implementation as long as the input file specifies the functionality correctly.

Link to comment
Share on other sites

just a thought: It seems you're aiming for "free" software on one side, but vendor-specific technology on the other (i.e. LUT capabilities are by no means standardized even between Xilinx generations, for example).

Wouldn't it make more sense to draw the line higher, at the level of generic / portable / inferable code? That is, code in a way that isn't tied to one specific vendor.

 

The vast majority of the Flavia tool chain is vendor-independent.  For example, you can simulate logic without caring about the eventual target FPGA.  It's only the last step that's vendor-specific.

 

The name Flavia is short for "Free Logic Array via --" where "--" is a specific FPGA architecture.  The first implementation is FlaviaP32 for Gadget Factory's Papilio One 250K, which I chose for various reasons.  But it's only the first implementation.  I'd like to see Flavia implementations on lots of different FPGAs, which FLOSS makes practical.

Link to comment
Share on other sites

It might be less work to emulate the FPGA in software. Verilator does an excellent job of translating Verilog into C++, or use iverilog's vvp interpreter.

That could be made to run on a Raspberry Pi, for example. With some GPIO magic, it could do a fairly good imitation of an FPGA.

Or even better, use a softcore CPU to run a software emulation of an FPGA on an FPGA :)

Link to comment
Share on other sites

This is a really great project! I just posted it out to the blog and all of the social media pages.

 

Let me know if there is anything I can do to help out. Maybe you would be willing to write some tutorials on learn.gadgetfactory.net? Or maybe we can have a Flavia promotion where anyone who orders a Papilio One 250K to use with Flavia gets a free B/LED Wing... Something like that.

 

Jack.

Link to comment
Share on other sites

It might be less work to emulate the FPGA in software. Verilator does an excellent job of translating Verilog into C++, or use iverilog's vvp interpreter.

That could be made to run on a Raspberry Pi, for example. With some GPIO magic, it could do a fairly good imitation of an FPGA.

Or even better, use a softcore CPU to run a software emulation of an FPGA on an FPGA :)

 

Logic simulation has been available for decades, and was one of the first major pieces of original software running on RasPi.  Simulation with a good user interface can be a useful tool, but as an engineer I find it's much more exciting to see my logic running as real hardware.  FPGAs are the closest most of us are going to get to designing custom chips, and IMO it's really satisfying to see hardware you designed performing functions that cannot be done in software because of performance and/or latency requirements.  I think one of the main problems with FPGAs is the steep learning curve associated with vendor tools, and Flavia is an attempt to address this.

Link to comment
Share on other sites

This is a really great project! I just posted it out to the blog and all of the social media pages.

 

Let me know if there is anything I can do to help out. Maybe you would be willing to write some tutorials on learn.gadgetfactory.net? Or maybe we can have a Flavia promotion where anyone who orders a Papilio One 250K to use with Flavia gets a free B/LED Wing... Something like that.

 

Jack.

 

Thank you so much for your kind comments and 'blog post.  I'll get back to you regarding ideas for next steps.  Right now my main project is fixing XXICC issues.  (XXICC is the hardware/software design system that's the front end for Flavia.)  In the push to get Flavia released by European Pi Day 22/7 I fell way behind on XXICC maintenance.

Link to comment
Share on other sites

Hi,

 

>> I think one of the main problems with FPGAs is the steep learning curve associated with vendor tools

that is true but simply because FPGA design is such a complex task.

 

>> because of performance and/or latency requirements

So you are promising performance, after all? But then you'll have to deal with all the real-world problems that make the vendor tools so complex. For example, timing analysis.

I think you can't have the cake and eat it.

 

IMO you should be very honest to people what they can realistically expect and what not, before guiding them into learning a new language etc.

Beginners don't have the visibility. If you're targeting newcomers by "simple first steps", I think you'll also have some responsibility to put them on a road that doesn't lead into a definite dead end after a couple of steps.

 

I don't even think the vendor tools are that bad. For example, this looks quite convincing.

Link to comment
Share on other sites

So you are promising performance, after all? But then you'll have to deal with all the real-world problems that make the vendor tools so complex.  For example, timing analysis.  I think you can't have the cake and eat it.

 

IMO you should be very honest to people what they can realistically expect and what not, before guiding them into learning a new language etc.

Beginners don't have the visibility. If you're targeting newcomers by "simple first steps", I think you'll also have some responsibility to put them on a road that doesn't lead into a definite dead end after a couple of steps.

 

I don't even think the vendor tools are that bad. For example, this looks quite convincing.

 

No, I'm not promising performance with Flavia.  I'm sorry if I gave that impression.  I've tried to be very clear about Flavia's limitations in the element14 'blog and other Flavia documentation.  In comment #8 above, I was referring to FPGAs in general and why a designer would want to use an FPGA instead of a microprocessor or microcontroller.

Regarding needing to "learn a new language, etc."  I personally think there are some significant problems with Verilog that make it hard for new users.  One that comes to mind immediately is the difference between "blocking" and "non-blocking" assignments, which I don't bother trying to explain even to myself.  I always use "<=" for assigning registers and "wire x = value" or "assign x = value" for assigning wires.  I can't remember if "<=" means "blocking" or "non-blocking", or what the terms mean intuitively.

Another Verilog issue is that it was created originally as a simulation language, with synthesis added as an afterthought.  As such, it's easy to write Verilog that simulates fine but cannot be synthesized.  Resolving this requires a new user to understand the synthesis process along with the rest of the learning curve, and it can be very frustrating.

I'm not experienced enough with VHDL to comment in detail, but since it was also first created as a simulation language without considering synthesis, I suspect it has similar issues.  In most of the discussions I read about Verilog versus VHDL, people argue about which language is worse, not which is better.

Flavia's textual language is "GalaxC for Hardware Design" (GCHD).  This language considered synthesis from the beginning.  In fact, many GCHD constructs are similar to the synthesizable Verilog subset I use for my professional FPGA designs.  So if you learn GCHD, most of that knowledge will carry over to Verilog, so IMO GCHD is hardly a dead end.

 

I don't even think the vendor tools are that bad.

I've gotten used to Xilinx ISE and can use it very effectively.  ISE produces excellent results.  But it took a lot of experience to get to the point where I could use ISE effectively.  I have an unfair advantage since I have a background in digital CAD, so I have a good idea how these tools work.  New users without that background probably have a harder time.

Link to comment
Share on other sites

Hi,

 

>> One that comes to mind immediately is the difference between "blocking" and "non-blocking" assignments, which I don't bother trying to explain even to myself.

>> I always use "<=" for assigning registers and "wire x = value" or "assign x = value" for assigning wires.

I'm a bit surprised to hear that if you use Verilog for a living. It is the most common job interview question. Shouldn't you learn the existing language really well before inventing a new one?

 

A "=" assignment to a register becomes visible to code further down the same block, so I can refer to the result instead of the original value. A "<=" assignment remains hidden to the next round.

It takes getting used to, yes.

But both are valid use cases: Sometimes I need to refer to the old value, sometimes to the current assignment result. This enables constructs ("temporary variables") that would be very clumsy if I simply enforce simple/misguided rules like "= for wires, <= for registers" without understanding.

It's there for a reason, not a flaw in the language.

 

>> As such, it's easy to write Verilog that simulates fine but cannot be synthesized.

But you don't expect the language to protect you from writing nonsense, do you? Is inventing your own language going to change that, except maybe on a superficial level?

I understand what you mean but again it's IMO not the language that's to blame but that people learn "simulator / testbench" flavor Verilog and then expect it to synthesize, when it should be the other way around.

 

Maybe the existing languages are victims of their own popularity: There is way too much material out there that confuses people, for example

- async examples when you need synchronous logic for FPGAs

- classroom material from authors lacking design experience

- too advanced

- newbie discussion or just plain wrong

- ...

But that is hardly a flaw of the language. Might just as well give up English because there are too many lousy books.

Link to comment
Share on other sites

Those are good comments and point out a number of ways that Verilog is challenging for a new user.  I prefer to follow Thoreau's advice: "Our life is frittered away by detail... Simplify, simplify."

No, I'm sorry, that is not my point. Please re-read.

Link to comment
Share on other sites

There is plenty wrong with VHDL and Verilog but I have to say the biggest problem I (and I think many people from a programming background) have is the business of thinking in parallel. Not just the idea that things like assignments take time and aren't instant but things like the fact that (except for power in some cases) it's actually not worth doing conditional evaluation of something, you can evaluate it every clock at no extra cost, in fact you can evaluate hundreds of un-needed things for free just in case they are relevant to a given cycle.

 

Not sure a language can help much with that. There is simply a gap between the conceptual model of programming and the reality of FPGA.

Link to comment
Share on other sites

There is plenty wrong with VHDL and Verilog but I have to say the biggest problem I (and I think many people from a programming background) have is the business of thinking in parallel. Not just the idea that things like assignments take time and aren't instant but things like the fact that (except for power in some cases) it's actually not worth doing conditional evaluation of something, you can evaluate it every clock at no extra cost, in fact you can evaluate hundreds of un-needed things for free just in case they are relevant to a given cycle.

 

Not sure a language can help much with that. There is simply a gap between the conceptual model of programming and the reality of FPGA.

 

Excellent points.  I think hardware designers have an easier time of it since they start by learning Boolean equations and logic diagrams where it's more clear that everything is going on in parallel.  Then you get to the Mealy model of sequential logic, where the combinational logic all evaluates in parallel, and then the state updates in parallel.  Parallelism becomes ingrained early on.

When I first learned software, flowcharts were still a popular way to illustrate program behavior.  These were all sequential flowcharts, so you quickly got the idea that one expression is evaluated at a time, and one variable gets updated at a time.  I don't know how they teach software nowadays, but it's probably some other sequential model.  After all, that's the model of what each CPU is doing at the machine language level.

Marketing would like you to believe that a C programmer can effortlessly become a Verilog designer because the languages have similar syntax.  In practice, I've heard that many C programmers try to write in Verilog as if it were C and produce terrible designs.  In fact, I heard a speaker at Design West 2013 (IIRC) say he preferred his FPGA designers to use VHDL instead of Verilog to make it obvious that they aren't using a programming language and must think differently :-)

Link to comment
Share on other sites

Marketing would like you to believe that a C programmer can effortlessly become a Verilog designer because the languages have similar syntax.  In practice, I've heard that many C programmers try to write in Verilog as if it were C and produce terrible designs.  In fact, I heard a speaker at Design West 2013 (IIRC) say he preferred his FPGA designers to use VHDL instead of Verilog to make it obvious that they aren't using a programming language and must think differently :-)

 

Hey! I think I was there for that same speaker! Was it in the common area? I can't remember his name or the topic, but I do remember him saying that because I use that now too. :)

Link to comment
Share on other sites

Hey! I think I was there for that same speaker! Was it in the common area? I can't remember his name or the topic, but I do remember him saying that because I use that now too. :)

 

I checked my notes.  The topic was "FPGA Design: What works and what makes you work weekends" at the Expo Theater on the exhibit floor on Wednesday, April 24, 2013.  Great talk.  The two speakers were Charles Fulks and RC Cofer.  According to my notes, it was Charles Fulks who made that comment about VHDL.

 

That was a great day for FPGAs at Design West AKA ESC.  Later was Duane Benson's "FPGAs: I know nothing... yet" where he talked about his challenges getting started with FPGAs and Verilog.  Duane's talk was great confirmation that something like Flavia is needed.  I unfortunately missed his follow-on talk at EE Live! earlier this year.  Great title: "FPGAs -- Light at the end of the learning curve".

Link to comment
Share on other sites

 

Thats confusing given that VHDL is a sort of bastardised ADA which is (allegedly) a programming language.

 

Alan is right. It may be considered a programming language (although I don't quite well understand 'allegedly a programming language' regarding ADA).

 

VHDL, unlike Verilog, does not even have a notion of hardware or anything like it. You can write normal code intended for CPUs in VHDL, but, since most VHDL is actually.... parallel, it might not be feasible to do so.

 

GHDL (which is the simulator I use) is based on GNATS, so you have a lot of ADA background there.

 

And, in case you believe ADA is only here for historical purposes (or believe that ADA is something like Pascal), let me tell you that ADA is not only still used, but it's one of the preffered languages on the aerospace industry.

 

Alvie

Link to comment
Share on other sites

  • 2 months later...

Flavia is now available for the Papilio One 500K!  The new "FlaviaP48" implementation is part of XXICC rev 0.0m, released 15 November 2014.  The software and documentation are in this 'blog at element14.

 

In addition, you can now set the Flavia clock to values from 1 Hz to 32 MHz instead of being stuck with the 2 Hz "proof of concept" clock.

Link to comment
Share on other sites

  • 6 months later...

Flavia is now available for the Papilio DUO!  The new "FlaviaPD59" implementation is part of XXICC rev 0.0p, released 15 May 2015.  The software and documentation are in this 'blog and this 'blog, both at element14.  I've only tested the 0.0p on GNU/Linux machines, so I don't know if there are any tricks needed to get Flavia's Papilio DUO implementation working on Windows.

Link to comment
Share on other sites

  • 4 weeks later...

XXICC rev 0.0q makes major improvements to the Papilio One versions of Flavia.  FlaviaP32 for the 250K is replaced with FlaviaP40, which has 40 arbitrary function blocks (AFBs).  FlaviaP40 also makes better use of Papilio One pins B0-B15, which were a kludge in FlaviaP32.  A0-A15 and C0-C15 are unrestricted I/Os.  B0-B15 are designed for use with Button/LED Wings.  Odd-numbered B pins are dedicated inputs (for buttons) and even-numbered B pins are I/Os (for LEDs).  FlaviaP40 AFBs can take inputs from any of the 48 Papilio I/O pins.

 

FlaviaP48 for the 500K is replaced with FlaviaP60, with 60 AFBs.  A0-A15, B0-B15, and C0-C15 are unrestricted I/Os.  FlaviaP60 also lets you access UART RXD and TXD, and the SPI Flash pins.  TXD (from FT2232D) is a dedicated input.  FlaviaP60 also has seven unpinned AFBs for internal logic.

 

Flavia I/O pins now have configurable pull-up, pull-down, and keeper circuits.  Finding those bits in the Spartan-3E bitstream was lots of fun -- depending on how you choose your amusements :)

 

Here's the release 'blog: http://www.element14.com/community/groups/fpga-group/blog/2015/06/28/xxicc-21st-century-co-design-release-00q

 

0.0q has a major re-write of Chapter 12 (Flavia) in http://www.element14.com/community/docs/DOC-77257/l/the-xxicc-anthology-rev-00q

Link to comment
Share on other sites

  • 2 years later...

XXICC rev 0.0r has just been released.  The main improvements are integer nets and operators, so you no longer need to express all logic as Boolean.  The Flavia back ends for Papilio One 250K/500K and Papilio Duo are unchanged.

Here's the release 'blog: https://www.element14.com/community/groups/fpga-group/blog/2017/08/24/xxicc-21st-century-co-design-release-00r

The XXICC Anthology rev 0.0r has new material for integers in Chapter 10 (GCHD) and splits the second part of Chapter 12 (Flavia) into new Chapters 13-14.  GCHD now has a back end for the open-source IceStorm tools for Lattice iCE40 FPGAs. 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.