designing a fpga

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all,

A couple of weeks ago, I was watching the talk of Wolf Clifford on his  
opensource fpga flow at ccc.
(
https://www.youtube.com/watch?v=SOn0g3k0FlE
)


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.



Re: designing a fpga
On 2/24/2017 2:32 AM, kristoff wrote:
Quoted text here. Click to load it

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

--  

Rick C

Re: designing a fpga
rickman wrote:

Quoted text here. Click to load it
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

Re: designing a fpga
On 2/24/2017 11:35 AM, Jon Elson wrote:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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

Re: designing a fpga
rickman wrote:


Quoted text here. Click to load it
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?
Quoted text here. Click to load it
Yes, I can believe that, too.  They really push the boundaries of what can  
be done in a process.
Quoted text here. Click to load it

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

Re: designing a fpga
On 2/24/2017 11:30 PM, Jon Elson wrote:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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

Re: designing a fpga
rickman wrote:

Quoted text here. Click to load it
 How about designing your own ring oscillator?
Quoted text here. Click to load it
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.


Quoted text here. Click to load it
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

Re: designing a fpga
On 2/27/2017 2:49 PM, Jon Elson wrote:
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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

Re: designing a fpga
rickman wrote:


Quoted text here. Click to load it
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

Re: designing a fpga
Quoted text here. Click to load it

I don't think that's a paradox.  There are no good books on Verilog, but that doesn't preclude it from being a good language.  Most textbooks (on any subject) are poor.

Re: designing a fpga
On 3/2/2017 3:19 PM, Kevin Neilson wrote:
Quoted text here. Click to load it

I didn't say it was a paradox.  I just prefer to have a good text to  
learn a language that I am going to use professionally.  I can't say I  
had that at the time I learned VHDL, but that was 20 years ago and I've  
learned from my mistakes in many ways.

I may try Verilog again sometime, but I would love to have a good  
reference to avoid making the various mistakes that I have heard of...  
things that you don't know happened until your design doesn't work  
*after* it has shipped.

--  

Rick C

Re: designing a fpga
Quoted text here. Click to load it

I just did a ring oscillator in a Virtex.  I had to instantiate the LUTs (figuring out the proper ROM value) and put KEEPs on them.  That was the only way to keep Vivado from pruning the logic.

Re: designing a fpga
On 3/2/2017 3:15 PM, Kevin Neilson wrote:
Quoted text here. Click to load it

If you just use HDL inversions with keeps on the nets it still optimizes?

--  

Rick C

Re: designing a fpga
rickman wrote:
Quoted text here. Click to load it

For the Xilinx tools, KEEP will not do the trick.  It only keeps the
nets until synthesis is complete.  Then the "Map" tool will optimize
away all but one inverter and leave you with just a single LUT
"oscillator."  However there is another attribute that keeps the
nets throughout the tool chain called "SAVE" or just "S".  This
will allow you to infer the ring oscillator like (Verilog):

module ring_osc
(
   output wire     clk_out
);

(* S = "TRUE" *) wire [4:0] inverters ;

assign inverters = ~;

assign clk_out = inverters[4];

endmodule

This same code with "KEEP" instead of "S" produced 5 inverters in
a loop after synthesis, but did not run through place & route
because "all logic has been removed."  With the "S" attribute as
shown, it generated a 5-LUT ring oscillator.

--  
Gabor

Re: designing a fpga
On 3/3/2017 11:47 AM, GaborSzakacs wrote:
Quoted text here. Click to load it

If the tool replaced five inverters with a null set, something  is  
wrong.  What was the basis for the removal of the logic?  The tool  
reports this, no?  I know mine does when P&R removes logic.

--  

Rick C

Re: designing a fpga
rickman wrote:
Quoted text here. Click to load it

Apparently it doesn't like implementing a "cycle," which is one way
of describing the ring.  Here's the relevent part of the Map report:

Section 1 - Errors
------------------
ERROR:Pack:198 - NCD was not produced.  All logic was removed from the  
design.
    This is usually due to having no input or output PAD connections in the
    design and no nets or symbols marked as 'SAVE'.  You can either add  
PADs or
    'SAVE' attributes to the design, or run 'map -u' to disable logic  
trimming in
    the mapper.  For more information on trimming issues search the Xilinx
    Answers database for "ERROR:Pack:198" and read the Master Answer  
Record for
    MAP Trimming Issues.

Section 2 - Warnings
--------------------
WARNING:Security:42 - Your software subscription period has lapsed. Your  
current
version of Xilinx tools will continue to function, but you no longer  
qualify for
Xilinx software updates or new releases.
WARNING:MapLib:701 - Signal clk_out connected to top level port clk_out  
has been
    removed.

Section 3 - Informational
-------------------------
INFO:Security:54 - 'xc7a100t' is a WebPack part.

Section 4 - Removed Logic Summary
---------------------------------
    7 block(s) removed
    6 signal(s) removed

Section 5 - Removed Logic
-------------------------

The trimmed logic reported below is either:
    1. part of a cycle
    2. part of disabled logic
    3. a side-effect of other trimmed logic

The signal "inverters<4>" is unused and has been removed.
  Unused block "inverters<4>1" (ROM) removed.
   The signal "inverters<3>" is unused and has been removed.
    Unused block "inverters<3>1" (ROM) removed.
     The signal "inverters<2>" is unused and has been removed.
      Unused block "inverters<2>1" (ROM) removed.
       The signal "inverters<1>" is unused and has been removed.
        Unused block "inverters<1>1" (ROM) removed.
         The signal "inverters<0>" is unused and has been removed.
          Unused block "inverters<0>1" (ROM) removed.
The signal "clk_out" is unused and has been removed.
  Unused block "clk_out_OBUF" (BUF) removed.
Unused block "clk_out" (PAD) removed.

This was run using Xilinx ISE (older) software.  Apparently Vivado
is even more picky about leaving your logic un-optimized.  ISE has
an option to "optimize instantiated primitives," but it's off by
default.  For Vivado you can't turn the equivalent function off
globally, meaning you need to add DONT_TOUCH to every primitive you
instantiate that might be a target for optimization.

--  
Gabor

Re: designing a fpga
On 3/3/2017 1:58 PM, GaborSzakacs wrote:
Quoted text here. Click to load it

Interesting.  If you give me the source I'll run it with the Lattice  
tools.  They use Synplify.  I want to add an input as well.  I assume a  
ring oscillator would want to be enabled in the real world, no?

--  

Rick C

Re: designing a fpga
Quoted text here. Click to load it

It's a combinatorial loop, i.e., the LUT output is a function of itself (before being registered).  I think all tools are going to prune it out.

Re: designing a fpga
On 3/3/2017 9:19 PM, Kevin Neilson wrote:
Quoted text here. Click to load it

I think not.  That is a latch if it has appropriate inputs such as a  
control line and a valid piece of logic.  I don't think they analyze the  
actual logic equations to see if it is stable.  It should have an  
enable.  I wouldn't build a ring oscillator in a design unless I had a  
way to shut it off.  Well, maybe if it was the main oscillator...

--  

Rick C

Re: designing a fpga
rickman wrote:
Quoted text here. Click to load it

Here's the latest iteration.  I found that when adding an enable, the
design builds correctly using just the KEEP attribute.  The SAVE
attribute is only required when there is no enable.  I increased
the number of stages so it was easier to simulate (post place&route).
With only 5 stages, the oscillations were too fast and the output
buffer simulation model didn't pass the signal through.

`timescale 1ns / 1ps
`default_nettype none

// `define USE_SAVE
`define USE_ENABLE

module ring_osc
#(
   parameter       STAGES = 15
)
(
`ifdef USE_ENABLE
   input wire      enable,
`endif
   output wire     clk_out
);

`ifdef USE_SAVE
(* S = "TRUE" *) reg [STAGES-1:0] inverters = };
`else
(* KEEP = "TRUE" *) reg [STAGES-1:0] inverters = };
`endif

`ifdef USE_ENABLE
always inverters = #0.15 ~{inverters[STAGES-2:0],inverters[STAGES-1] &  
enable};
`else
always inverters = #0.15 ~;
`endif

assign clk_out = inverters[STAGES-1];

endmodule
`default_nettype wire

Site Timeline