EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

designing a fpga

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - designing a fpga

Goto page Previous  1, 2, 3  Next

rickman
Guest

Mon Feb 27, 2017 2:32 am   



On 2/25/2017 8:36 PM, thomas.entner99_at_gmail.com wrote:
Quote:
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
Wink


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

Rick C. Hodgin
Guest

Mon Feb 27, 2017 7:13 pm   



On Friday, February 24, 2017 at 2:43:45 AM UTC-5, kristoff wrote:
Quote:
... 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

Jon Elson
Guest

Tue Feb 28, 2017 2:49 am   



rickman wrote:

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


Quote:
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

rickman
Guest

Tue Feb 28, 2017 3:12 am   



On 2/27/2017 2:49 PM, Jon Elson wrote:
Quote:
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.


Quote:
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

Jon Elson
Guest

Thu Mar 02, 2017 3:00 am   



rickman wrote:


Quote:
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

Kevin Neilson
Guest

Thu Mar 02, 2017 10:15 pm   



Quote:

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

Kevin Neilson
Guest

Thu Mar 02, 2017 10:19 pm   



Quote:
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


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.

rickman
Guest

Fri Mar 03, 2017 7:04 am   



On 3/2/2017 3:19 PM, Kevin Neilson wrote:
Quote:
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

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.


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

rickman
Guest

Fri Mar 03, 2017 7:14 am   



On 3/2/2017 3:15 PM, Kevin Neilson wrote:
Quote:

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


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

--

Rick C

Kevin Neilson
Guest

Fri Mar 03, 2017 6:52 pm   



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

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

--

Rick C


Yes, I just looked at the code, and in my comments I say I had to instantiate the LUTs (and put DONT_TOUCH directives on them). Even with the directives, when I wrote it in behavioral HDL, the logic got pruned away by Vivado.. This is for a random number generator so for sim the code uses the Verilog $random function.

GaborSzakacs
Guest

Fri Mar 03, 2017 11:47 pm   



rickman wrote:
Quote:
On 3/2/2017 3:15 PM, Kevin Neilson 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 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.

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


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 = ~{inverters[3:0],inverters[4]};

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

rickman
Guest

Fri Mar 03, 2017 11:57 pm   



On 3/3/2017 11:47 AM, GaborSzakacs wrote:
Quote:
rickman wrote:
On 3/2/2017 3:15 PM, Kevin Neilson 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 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.

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


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 = ~{inverters[3:0],inverters[4]};

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.


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

GaborSzakacs
Guest

Sat Mar 04, 2017 1:58 am   



rickman wrote:
Quote:
On 3/3/2017 11:47 AM, GaborSzakacs wrote:
rickman wrote:
On 3/2/2017 3:15 PM, Kevin Neilson 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 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.

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


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 = ~{inverters[3:0],inverters[4]};

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.

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.


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

Jon Elson
Guest

Sat Mar 04, 2017 3:42 am   



Kevin Neilson wrote:

Quote:

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 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.
Yes, that seems to be the way you do it.


Jon

Rob Gaddi
Guest

Sat Mar 04, 2017 4:14 am   



On 03/03/2017 12:42 PM, Jon Elson wrote:
Quote:
Kevin Neilson 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 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.
Yes, that seems to be the way you do it.

Jon


Back in the day, I did it with a hard macro, just to make sure that the
path lengths didn't go all over the place with every new recompile.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

Goto page Previous  1, 2, 3  Next

elektroda.net NewsGroups Forum Index - FPGA - designing a fpga

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map