designing a fpga

[Kevin Neilson]

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]

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]

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

--

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]

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?

--

Rick C

 

[Kevin Neilson]

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]

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.

--
Gabor

 

[rickman]

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.

--

Rick C

 

[GaborSzakacs]

rickman wrote:

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
------------------
ERRORack: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 "ERRORack: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]

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

 

[Rob Gaddi]

On 03/03/2017 12:42 PM, Jon Elson wrote:

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.

 

[Kevin Neilson]

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

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.

 

[rickman]

On 3/3/2017 1:58 PM, GaborSzakacs wrote:

rickman wrote:
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
------------------
ERRORack: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 "ERRORack: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.

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

 

[Jon Elson]

Rob Gaddi wrote:

On 03/03/2017 12:42 PM, Jon Elson wrote:
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.

Yes, you have to. The delays in even local interconnect will be many times
the propagation delay through the LUTs. If you want predictable clock rate,
you have to at least relatively lock down the whole section.

Jon

 

[rickman]

On 3/3/2017 9:19 PM, Kevin Neilson wrote:

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

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.

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

 

[GaborSzakacs]

rickman wrote:

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?

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 = {STAGES/2{2'b10}};
`else
(* KEEP = "TRUE" *) reg [STAGES-1:0] inverters = {STAGES/2{2'b10}};
`endif

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

assign clk_out = inverters[STAGES-1];

endmodule
`default_nettype wire

 

[Kevin Neilson]

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

I haven't seen this SAVE directive. I don't think it's mentioned in the Vivado Synthesis Guide--only KEEP and DONT_TOUCH. Is it equivalent to the latter?

I based my ring oscillators on the interlinked XORs in this paper. They're supposed to be more chaotic, which is good if what you are looking for is random numbers.

https://pdfs.semanticscholar.org/83ac/9e9c1bb3dad5180654984604c8d5d8137412.pdf

 

[Kevin Neilson]

I honestly haven't ever used it in my actual designs (nor do I use
ring oscillators), but I saw it suggested in the trimming report.
I was mostly pointing out that it is possible (though not recommended)
to infer a ring oscillator in ISE. The only cases where I've seen
ring oscillators used was in evaluation IP where the oscillator was
used to generate a timeout that disables the IP functionality when
it is not fully licensed.

--
Gabor

I might have to try out that directive. DONT_TOUCH is supposed to preserve something through map and PAR, but often, like with a lot of directives, Vivado will choose to ignore it. Sometimes it also changes the name.

I used the ring oscillator described in that link to make a true random number generator for inserting errors into a wide, high-speed bus. I haven't tested the hardware yet but everything looks good after PAR.

 

[GaborSzakacs]

Kevin Neilson wrote:

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

I haven't seen this SAVE directive. I don't think it's mentioned in the Vivado Synthesis Guide--only KEEP and DONT_TOUCH. Is it equivalent to the latter?

I based my ring oscillators on the interlinked XORs in this paper. They're supposed to be more chaotic, which is good if what you are looking for is random numbers.

https://pdfs.semanticscholar.org/83ac/9e9c1bb3dad5180654984604c8d5d8137412.pdf

It's a map directive, so it may still be in Vivado, but not in the
synthesis guide. In ISE it's in the Constraints Guide. Here's the
description:

Save Net Flag
The Save Net Flag (SAVE NET FLAG) constraint:
• Is a basic mapping constraint.
• When attached to nets or signals, affects mapping, placement, and
routing by preventing the removal of unconnected signals.
• Prevents the removal of loadless or driverless signals.
– For loadless signals, Save Net Flag acts as a dummy OBUF load connected to
the signal.
– For driverless signals, Save Net Flag acts as a dummy IBUF driver
connected
to the signal.
• Can be abbreviated as S NET FLAG.
If you do not have Save Net Flag on a net, any signal that cannot be
observed or controlled via a path to an I/O primitive is removed.
Save Net Flag may prevent the trimming of logic connected to the signal.

I honestly haven't ever used it in my actual designs (nor do I use
ring oscillators), but I saw it suggested in the trimming report.
I was mostly pointing out that it is possible (though not recommended)
to infer a ring oscillator in ISE. The only cases where I've seen
ring oscillators used was in evaluation IP where the oscillator was
used to generate a timeout that disables the IP functionality when
it is not fully licensed.

--
Gabor

 

[Rick C. Hodgin]

On Sat, 25 Feb 2017 09:37:46 -0500, Rick C. Hodgin
<rick.c.hodgin@gmail.com> wrote:

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]

I have continued this idea with some development toward what I'm
probably going to start calling an I/O CPU. It is built around
a cell core, which has the ability to process in a myriad of
ways around a 64-bit piece of data. It can communicate with its
North, South, East, West neighbors, and retrieve from their 64-
bit data as well. Eight 8-bit cores exist in each cell, which
are able to operate independently, or in ganged mode, allowing
for a wide range of processing models. An executive manager
sits atop each cell, and is coordinated with it via a parallel
instruction stream which has some general purpose computing,
as well as being able to coordinate reads and writes to other
system buses, including masked reads/writes to fixed I/O data
pins which are sampled independently and copied onto the main
bus available data input and output.

An array of 3x3 of these cells operate, and you can see some
of the preliminary work here. I am calling it Arlina FPGA,
but that name will soon be changed to Arlina I/O CPU:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arlina

You can see my previous L1 cache design here:

http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/cache_l1/cache1__4read_4write_poster.png

It is an 8-bit cache cell, which is aggregated up to a 128-
bit cache row, which is aggregated up to 16KB instruction,
and 32KB data, supporting 40-bit data and 40- to 44-bit
addresses.

Thank you,
Rick C. Hodgin