designing a fpga

Hi Jon,

On 24-02-17 17:35, Jon Elson wrote:
> 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!

A couple of days ago, I found this video:
https://media.ccc.de/v/froscon2016-1817-how_to_design_your_own_chip

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.



> 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.

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 
(http://www.rowetel.com/?page_id=452).
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?


> Jon
Cheerio! Kr. Bonne

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

> 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?

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.

Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:
> > 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?
> 
> 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.

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 Clifford does with YOSYS, etc. sounds extremely impressive (I have not never tested 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, simply because it is incredible expensive. Of course you can use a big FPGA to simulate 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-inputs LUTs (the key patents have already expired, I guess) - or you invent some improved more or less radical new architecture. This would be a big (and 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 the existing players. There is a reason why so many FPGA start-ups failed. But this does not mean that it cannot be done, of course... Personally I would find it cool to have an Austrian FPGA ;-)

Regards,

Thomas

www.entner-electronics.com - Home of EEBlaster and JPEG Codec

Hallo,



On 26-02-17 02:36, thomas.entner99@gmail.com wrote:
> Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:
>>> 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?

>> 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.

> 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 Clifford does with YOSYS, etc. sounds extremely impressive (I have not never tested 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.

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

If you look at the codec2 project (the low-bit voice codecà. It started 
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.




 > From a practical point, however, the hardware is much more difficult, 
simply because it is incredible expensive. Of course you can use a big 
FPGA to simulate 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-inputs LUTs (the key patents have already expired, I guess) - 
or you invent some improved more or less radical new architecture. This 
would be a big (and 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 the existing players. There is a reason why so many FPGA 
start-ups failed. But this does not mean that it cannot be done, of 
course... Personally I would find it cool to have an Austrian FPGA ;-)


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.



> Regards,
> Thomas
Cheerio! Kr. Bonne.

On 2/25/2017 8:36 PM, thomas.entner99@gmail.com wrote:
> Am Samstag, 25. Februar 2017 18:50:45 UTC+1 schrieb Kevin Neilson:
>>> 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?
>>
>> 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.
>
> 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 Clifford does with YOSYS, etc. sounds extremely impressive (I
> have not never tested 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,
> simply because it is incredible expensive. Of course you can use a
> big FPGA to simulate 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-inputs LUTs (the key patents have already expired, I
> guess) - or you invent some improved more or less radical new
> architecture. This would be a big (and 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 the existing players. There is a reason why so many FPGA
> start-ups failed. But this does not mean that it cannot be done, of
> course... Personally I would find it cool to have an Austrian FPGA
> ;-)

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

On Friday, February 24, 2017 at 2:43:45 AM UTC-5, kristoff wrote:
> ... Wolf Clifford ... opensource fpga flow at ccc ...
>
> 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?

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

Thank you,
Rick C. Hodgin

rickman wrote:

> On 2/24/2017 11:30 PM, Jon Elson wrote:
 How about designing your own ring oscillator?
> 
> I'm not sure how to even do that in an HDL.
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.


> 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?
> 
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

On 2/27/2017 2:49 PM, Jon Elson wrote:
> rickman wrote:
>
>> On 2/24/2017 11:30 PM, Jon Elson wrote:
>  How about designing your own ring oscillator?
>>
>> I'm not sure how to even do that in an HDL.
> 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.
>
>
>> 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?
>>
> Just that I would expect it to give the simulator indigestion!

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 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.

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

rickman wrote:


> 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.
> 
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