FPGARelated.com
Forums

designing a fpga

Started by kristoff February 24, 2017
> > > 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.
> 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.
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
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
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
> > I just did a ring oscillator in a Virtex. I had to instantiate the LUT=
s (figuring out the proper ROM value) and put KEEPs on them. That was the = only way to keep Vivado from pruning the logic.
>=20 > If you just use HDL inversions with keeps on the nets it still optimizes? >=20 > --=20 >=20 > Rick C
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.
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
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. -- Gabor
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
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.