designing a fpga

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

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.

s (figuring out the proper ROM value) and put KEEPs on them. That was the only way to keep Vivado from pruning the logic.

Yes, I just looked at the code, and in my comments I say I had to instantia te the LUTs (and put DONT_TOUCH directives on them). Even with the directi ves, 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 Veril og $random function.

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" is unused and has been removed. Unused block "inverters1" (ROM) removed. The signal "inverters" is unused and has been removed. Unused block "inverters1" (ROM) removed. The signal "inverters" is unused and has been removed. Unused block "inverters1" (ROM) removed. The signal "inverters" is unused and has been removed. Unused block "inverters1" (ROM) removed. The signal "inverters" is unused and has been removed. Unused block "inverters1" (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.

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.

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?

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

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

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

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.

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.

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.

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:

You can see my previous L1 cache design here:

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