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

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

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

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

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

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

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

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

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

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

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.