designing a fpga

Hi all,

A couple of weeks ago, I was watching the talk of Wolf Clifford on his opensource fpga flow at ccc.

formatting link

At the end, he mentions designing an open-source fpga and the replies he got when he mentioned the idea to hardware-companies. Appart from the question about the usefullness or economic viability of the idea itself (1), it did get me thinking.

Question, can I conclude from his remark that -if a hardware companie would start out with designing a fpga- that the problem is more the "software" side of things than the actual hardware design of the chip.

Or is this conclussion a bit to easy?

Cheerio! Kr. Bonne.

Reply to
kristoff
Loading thread data ...

Nearly two decades ago (well, 15 years anyway) folks from Xilinx said they spent more on software development than developing the chips.

--

Rick C
Reply to
rickman

Hodgin posted this link a while ago:

formatting link

Reply to
Johann Klammer

It is easy to believe this is true. The FPGA needs a fair bit of careful design and testing, but the structure is quite simple. You need to make sure the LUTs are glitchless and that you know the timings. That is about it.

THEN, you get to the software side. You need to be able to take in all the suboptimal and blatantly bad HDL that users will throw at it, and at least give coherent error messages and not crash. There are probably so MANY ways to write bad HDL that has unintended side effects, races and logic hazards. While the FPGA is a massively repeated set of very simple identical cells, the software has to treat it as thousands of different components once the LUT patterns have been loaded. I'm GLAD somebody else is doing all this work!

To make your own FPGA, probably the BIGGEST minefield is the patent arena. There must be thousands of current patents on FPGAs and FPGA-like devices and tons of old prior art that could make patenting anything you design problematic. Even if you had no intention of filing for a patent, you'd have to design very carefully so as not to step on one of the "big boys" patents. There is also lots of prtections files on software IP that you'd have to avoid.

Jon

Reply to
Jon Elson

In 2004 ST started the most serious Open FPGA project I am aware of:

formatting link

Sadly they gave up in early 2005.

-- Jecel

Reply to
Jecel

I think you are oversimplifying the design of an FPGA by quite a large margin. I believe the most important part of FPGAs is the routing and overall architecture. I am sure they put tons of effort into optimizing every aspect of the logic as well as the routing for timing and power consumption, the two most important parameters of FPGAs.

The design of all the various special functions take no small amount of effort too, the clock blocks are a good example. Then there are multipliers and memory, all of which must be optimized for the process. In fact, my understanding is that the FPGA vendors are a large contributor to the development of the processes used at the foundries.

I don't think writing code to read text and not crash is actually all that hard. The tool vendors don't care about logic hazards, that is the domain of the designer.

Certainly if you wish to make a state of the art FPGA it would involve dodging a great many patents. But to design *a* FPGA would not be so hard. In fact expired patents would be your pool of resources to draw from. The basic LUT used as logic and memory are out of patent along with everything used in devices like the XC4000 series. If I were designing a chip and wanted to include FPGA fabric, I could do worse than to duplicate the functionality of that device.

--

Rick C
Reply to
rickman

OK, yes, I WAS oversimplifying. My point (badly stated) was that the FPGA designers hold all the cards, they fully specify the LUTs, the routing matrix, the IOBs, etc. The SOFTWARE, however, has to deal with all the pathological and just totally unexpected things people will try to do with an FPGA. How about designing your own ring oscillator?

Yes, I can believe that, too. They really push the boundaries of what can be done in a process.

OK, maybe not "crash", but produce unintelligable error messages, or just totally screwy results, with NO error messages. Yes, now I must admit, some of my legacy designs that have been dragged along from 5V Spartan to Spartan

2E to Spartan 3A still have a bunch of crud left over from their old history and mediocre hacking. But, I've had a few situations where ISE didn't like what I'd given it, and had to just recompose some portion of the logic. I never understood what was wrong with my VHDL, but changing the way I'd written the equations just slightly made it work. Fortunately, I have had very few of these situations, and for the most part ISE works amazingly well, and I'm NOT complaining. I'm just aware that there are so many ways to structure HDLs, and so many things one can do with it, that it seems very complicated to make it all work.

Jon

Reply to
Jon Elson

I'm not sure how to even do that in an HDL. I suppose you can have a second input to each inverter and set bits in a register to enable it. But it would still have an combinatorial feedback path which would flag an error in the timing analyzer unless you except that path. Where do you see the problem?

The tools don't cope with a lot of crazy stuff. If the inputs are too wacky, they just give an error message.

It's all rule based. As long as you follow the rules it will synthesize. I remember my first VHDL design. I used some of the features that seemed useful and no one told me not to (it was an Orcad tool believe it or not). It was so terrible we switched to the Xilinx tool (I don't recall the origin of that tool). I was using '-' for don't cares in comparisons. Then we had a tool update and Xilinx switched the synthesis engine on us. The don't cares didn't work anymore as well as many other issues. Back in those days I think the vendors tried to ignore some aspects of the VHDL standard and let you get away with some things and not others and of course, each vendor was different. So I wrote my code three times for that project.

--

Rick C
Reply to
rickman

Hi Jecel, Rickman, Jon, Johann, ... all

Interesting.

Now I do get the impression that open-source hardware (and related issues) is something that just now has started to become of age. (perhaps opensparc was also years to soon).

Appart from the icestorm tool, I now found this project: Trollstigen

formatting link

Also here:

formatting link

I think it's interesting in two ways:

- it's really a open-source fpga design so it proves in principe that this can be done.

- it seams to be based on a different flow: VTR (verilog to routing,

formatting link
on which they added their own bitstream-generator

Now, i am far being an expert in fpga expert (hence all my questions here :-) ) but from what I understand about it, this means there are two options on the table:

- completely open-source: open-source fpga hardware + open-source tools

- closed-source fpga hardware + open-source tools (except for the bitstream generator, which would then be closed source).

I am correct, the actual knowledge of the internals of the FPGA is in the bitstream generator, so if a company does not want to expose that information, it would be enough to use a closed-source tool for that.

Well free to correct me if I am wrong.

Cheerio! Kr. Bonne.

Reply to
kristoff

A company can *try* to keep their chip design info closed, but if a bunch of amateurs can reverse engineer one company's devices, it shouldn't be too hard to reverse engineer them all. It is a matter of time and the need. To date no commercial effort has needed to reverse engineer FPGA bitstreams. But a bunch of amateurs showed it could be done.

The trouble with open source hardware is that having one made is not inexpensive. For board level items it is not terribly practical unless it is a niche item you just can't find elsewhere. For chip level devices personal manufacturing is prohibitively expensive. Even decades old technology is not cheap to have a minimum run made. Ask Green Arrays.

--

Rick C
Reply to
rickman

A couple of days ago, I found this video:

formatting link

It's a very good overview on the tools that are out there for vlsi, fpga design, testing-tools, ... and how hacker/maker/hobbyist friendly they are, including some ways to get them foundries.

So there seams to be quite a few tools out there. Concerning FPGAs, there seams to be two tools that go all the way up generating a fpga bitstream. Wolf is now working on the "timing verification" part for his tools.

I think Rickman made a valid remark that quite some technologie is based on patents that have expired.

This kind of reminds me of the "codec2" project

formatting link
. It was also thought that low-bitrates voice codecs where littered with patents, but it turned out that it is possible to create a (now down-to

700 bps) voice codec just based on public domain knowledge.

Do mind, I am not saying that this is also the cases here, just it is "to be verified".

Now, for me, the question that interests me is this:

For an fpga, you need two things: hardware and software.

If

- the software-component is now becoming available as open-source tools (and let's make the assumtion that this will continue to be the case in the near future),

and

- the hardware-component seams to be the less-difficult part of the process (especially for companies that already design and make ICs, be it not fpgas),

could the conclussion then be that -in a couple of years- will result in more competition in the fpga-market? (probably starting at the low-end part of the market)?

Or is this conclussion a bit to easy?

Cheerio! Kr. Bonne

Reply to
kristoff

I've been considering designing my own fpga to go with my Logician tool. I would call it Si-Block ("sigh-block," or SiB for short). It would allow unlimited logic with a decreasing performance level the more complex it got, running on a saturating clock that fires maximally at frequency, but otherwise only when each cycle completes fully. It would be inexpensive, with full debug abilities, and room to expand.

Stack:

0: [SiB hardware] 1: [Logician, simulation + SiB compiler] 2: [HLL Compilers, able to also output to Logician] 3: [IDE / text editors, express in some language] 4: [Human ideas]

Thank you, Rick C. Hodgin

Reply to
Rick C. Hodgin

I'd agree with this. I'd say the silicon these days is pretty great and the software is the limitation. It's not for lack of effort, though. I think most of the resources of an FPGA company go into the software side.

I don't quite understand the interest in an open-source FPGA. I don't believe it would be better than what we are getting commercially.

The areas that need the greatest improvement are open to development. There's nothing stopping somebody from making a better synthesizer. Convert HDL to structural code. You can still use this with commercial tools.

Reply to
Kevin Neilson

Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:

the software is the limitation. It's not for lack of effort, though. I th ink most of the resources of an FPGA company go into the software side.

lieve it would be better than what we are getting commercially.

ere's nothing stopping somebody from making a better synthesizer. Convert HDL to structural code. You can still use this with commercial tools.

I basically fully agree (except maybe that also P&R might be an interesting topic which is pretty closed). But I want to add some further comments:

From a technical point, the software is the most difficult. While what Clif ford does with YOSYS, etc. sounds extremely impressive (I have not never te sted it yet - no time...), it will be next to impossible to find sufficient skilled programmers (in both programming and FPGA design) that contribute for free, IMHO.

From a practical point, however, the hardware is much more difficult, simpl y because it is incredible expensive. Of course you can use a big FPGA to s imulate the "new" FPGA for a start. But at some point you will want to have real chips for the whole project to make sense. And then you have a multi- million Euro/dollar project...

You have to find a business case for the one how pays this millions (if you find someone at all...), and it will most likely be not open source?

The next difficult thing about hardware is (beside the patent topic others have already mentioned): Either you make a "me too" hardware, based on 4-in puts LUTs (the key patents have already expired, I guess) - or you invent s ome improved more or less radical new architecture. This would be a big (an d interesting task) on it's own, of course... Maybe, at the end of Moore's law (?), a clever new architecture could bring a real benefit...

Business cases that come to my mind are things like:

- new FPGA vendor

- offer embedded FPGA technology for ASIC suppliers

You will need to be able support the customers, etc. and compete against th e existing players. There is a reason why so many FPGA start-ups failed. Bu t this does not mean that it cannot be done, of course... Personally I woul d find it cool to have an Austrian FPGA ;-)

Regards,

Thomas

formatting link
- Home of EEBlaster and JPEG Codec

Reply to
thomas.entner99

Hallo,

Well, my guess is that the key to this is "information", or -to put it otherwize- demythifying the technology.

out as a one-person project of David , but he did a lot of effort to really explain the technology and its core concepts. (there are quite a few videos from presentation about this on the web).

It is not that this means you end up with hunderd of coders, but it does really help to "demythify" a technology, provide a "starting point" for who is interesed and get a few people around you.

Also keep in mind that more then 60 % of the code in (e.g.) the linux-kernel is actually written by people who are on the payrole of big IT companies.

Perhaps the most logical community for this are the people who are now involved in the risc-V CPU.

One of the ideas I find interesting what is done by a company called "SiFive": they provide help to companies who want to integrate the risc-V CPU in their own design. (1)

That's also why their business-model works very well with open-source hardware model. Their product is not the CPU itself, nor a customised versions of the risc-V, but a service: the process of integrating and customising the risc-V for the customer.

In fact, the fact that actually making the hardware is so expensive is

-their this business model- not necessairy a bad thing. There are relative few people are able to "steal" your effort and create CPUs to compete with you. This makes donating your work back to the open-source community less risky then in the software world.

(1) SiHive also offers the HiFive-1 (a RV32-based dev-kit), designed as a way to let people get their hands on a risc-v CPU.

Cheerio! Kr. Bonne.

Reply to
kristoff

There are lots of great chips out there and as has been done for a few Lattice parts, they can be reverse engineered to get past the bitstream issue.

What I would like to see is a different approach to the design software. In the early days FPGA place and routing was done with a large amount of hand work. As technology progressed the tools did better and better designs. As designs got larger and larger it became essential that the software would take over from the designer and essentially handle all aspects of place and route.

I tend to work on smaller projects where it would be practical for the designer to be more intimately involved in the placement and routing... well, the placement anyway. Routing is no fun! I'd like to see tools that allow construction of logical blocks using the device provided primitives in a hierarchical fashion that supports easy placement control. Once a good placement is found, auto-routing is made much easier. Yes, this can be done in HDL in theory, but it is not so easy and very verbose.

--

Rick C
Reply to
rickman

Kristoff, I am so happy that you started this thread. It has given me much to think about.

Thank you, Rick C. Hodgin

Reply to
Rick C. Hodgin

Yes, I didn't do it, but we have a design that has a 33 MHz ring oscillator that is some piece of IP. I never looked to see how it was coded. This is on a Spartan 3AN part.

Just that I would expect it to give the simulator indigestion!

I started out with CPLDs, doing schematic entry. Then, I moved to FPGAs, and schematic entry worked, but led to a lot of maintenance hassles. I finally saw the light, and learned VHDL.

Jon

Reply to
Jon Elson

Certainly the pre-layout simulation will not oscillate at 33 MHz. Likely it will either not oscillate or will oscillate with delta delays (zero time) unless they use specific features to assign delays in simulation.

I still don't see why this is so hard to deal with in tools. The tools either see correct inputs or not.

I know someone who adamantly insists Verilog is much more productive. But every time I ask about a good reference book that will teach me how to avoid the various pitfalls (learn from other's experience rather than my own) of Verilog I'm told there isn't one. Go figure.

Why did you pick VHDL? Initially it is a PITA to learn. The strong typing can really tie you up in knots.

--

Rick C
Reply to
rickman

My understanding is that if you are doing numerical algorithms like cryptology, FFTs, image processing, and testing them in C, then it is MUCH easier to convert them to Verilog.

If you are doing much more hardware-y type stuff, then VHDL may be more direct. I don't MIND strong typing, and automatic type conversions can really trip you up. I rarely have to do explicit type conversions in VHDL, it does allow a fair bit of automatic stuff. Like, you can assign an integer to a bit vector without a type conversion.

I've never run into a type conversion that was not already provided by one of the libraries.

I did do a stupid, do-nothing-tron project when learning VHDL to find out how to write up some of the tricky things, like instantiating rows and columns of my own defined blocks. So, I had a FF with an output multiplexer and an input decoder that enabled the clock, and then instantiated a row of

10 of them, then 10 rows of those. So, in about 20 lines of VHDL I had 100 FFs with input and output selectors. I thought that was a pretty neat accomplishment at the time.

Jon

Reply to
Jon Elson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.