Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 2/27/2017 2:49 PM, Jon Elson wrote: > 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. > 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 CArticle: 159776
rickman 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. > 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. JonArticle: 159777
> > > 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.Article: 159778
> 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.Article: 159779
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 CArticle: 159780
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 CArticle: 159781
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
Article: 159782> > 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.Article: 159783
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
Article: 159784
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
Article: 159785Kevin 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. JonArticle: 159786
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.Article: 159787
Has anybody used these? We have two FPGAs on a board, a Zynq and an Artix7. We want to use the internal ADCs to read chip temperatures. We have been advised to ground the temp sense diode pins DXP and DXN "if they are not being used". Unless the XADC has a separate temp sense diode, seems to me that shorting the external diode pins might kill our ability to acquire temperature internally. I don't see any big downside to not grounding those pins. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 159788
On Fri, 03 Mar 2017 13:34:58 -0800, John Larkin <jjlarkinxyxy@highlandtechnology.com> wrote: >Has anybody used these? > >We have two FPGAs on a board, a Zynq and an Artix7. We want to use the >internal ADCs to read chip temperatures. We have been advised to >ground the temp sense diode pins DXP and DXN "if they are not being >used". > >Unless the XADC has a separate temp sense diode, seems to me that >shorting the external diode pins might kill our ability to acquire >temperature internally. > >I don't see any big downside to not grounding those pins. After too much research, it seems that there are independent temp sensors, the external-pin one and another inside the XADC. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 159789
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
Article: 159790Rob 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. JonArticle: 159791
> 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.Article: 159792
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 CArticle: 159793
On Fri, 03 Mar 2017 14:00:17 -0800, John Larkin wrote: > On Fri, 03 Mar 2017 13:34:58 -0800, John Larkin > <jjlarkinxyxy@highlandtechnology.com> wrote: > >>Has anybody used these? >> >>We have two FPGAs on a board, a Zynq and an Artix7. We want to use the >>internal ADCs to read chip temperatures. We have been advised to ground >>the temp sense diode pins DXP and DXN "if they are not being used". >> >>Unless the XADC has a separate temp sense diode, seems to me that >>shorting the external diode pins might kill our ability to acquire >>temperature internally. >> >>I don't see any big downside to not grounding those pins. > > After too much research, it seems that there are independent temp > sensors, the external-pin one and another inside the XADC. And they recommend grounding DXP and DXN to improve the ESD rating. IIRC there's no functional issue caused by leaving them open. Regards, AllanArticle: 159794
On 04 Mar 2017 10:52:06 GMT, Allan Herriman <allanherriman@hotmail.com> wrote: >On Fri, 03 Mar 2017 14:00:17 -0800, John Larkin wrote: > >> On Fri, 03 Mar 2017 13:34:58 -0800, John Larkin >> <jjlarkinxyxy@highlandtechnology.com> wrote: >> >>>Has anybody used these? >>> >>>We have two FPGAs on a board, a Zynq and an Artix7. We want to use the >>>internal ADCs to read chip temperatures. We have been advised to ground >>>the temp sense diode pins DXP and DXN "if they are not being used". >>> >>>Unless the XADC has a separate temp sense diode, seems to me that >>>shorting the external diode pins might kill our ability to acquire >>>temperature internally. >>> >>>I don't see any big downside to not grounding those pins. >> >> After too much research, it seems that there are independent temp >> sensors, the external-pin one and another inside the XADC. > >And they recommend grounding DXP and DXN to improve the ESD rating. IIRC >there's no functional issue caused by leaving them open. > >Regards, >Allan Right, the esd thing makes no sense at all. -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159795
On Sat, 04 Mar 2017 09:29:14 -0800, John Larkin wrote: > On 04 Mar 2017 10:52:06 GMT, Allan Herriman <allanherriman@hotmail.com> > wrote: > >>On Fri, 03 Mar 2017 14:00:17 -0800, John Larkin wrote: >> >>> On Fri, 03 Mar 2017 13:34:58 -0800, John Larkin >>> <jjlarkinxyxy@highlandtechnology.com> wrote: >>> >>>>Has anybody used these? >>>> >>>>We have two FPGAs on a board, a Zynq and an Artix7. We want to use the >>>>internal ADCs to read chip temperatures. We have been advised to >>>>ground the temp sense diode pins DXP and DXN "if they are not being >>>>used". >>>> >>>>Unless the XADC has a separate temp sense diode, seems to me that >>>>shorting the external diode pins might kill our ability to acquire >>>>temperature internally. >>>> >>>>I don't see any big downside to not grounding those pins. >>> >>> After too much research, it seems that there are independent temp >>> sensors, the external-pin one and another inside the XADC. >> >>And they recommend grounding DXP and DXN to improve the ESD rating. >>IIRC there's no functional issue caused by leaving them open. >> >>Regards, >>Allan > > Right, the esd thing makes no sense at all. Why do you say it makes no sense? A lot of devices have an improved ESD rating when their more sensitive pins are connected to low impedance sources (as opposed to being open). Of course, if those pins are on a via-less pad under a BGA on a PCB with good planes, the difference may be hard to measure. Regards, AllanArticle: 159796
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
Article: 159797
> `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
Article: 159798
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
Article: 159799> 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.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z