Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 159775

Article: 159775
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Mon, 27 Feb 2017 15:12:37 -0500
Links: << >>  << T >>  << A >>
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 C

Article: 159776
Subject: Re: designing a fpga
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 01 Mar 2017 14:00:23 -0600
Links: << >>  << T >>  << A >>
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.


Jon

Article: 159777
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 2 Mar 2017 12:15:06 -0800 (PST)
Links: << >>  << T >>  << A >>
> 
> > 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
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Thu, 2 Mar 2017 12:19:04 -0800 (PST)
Links: << >>  << T >>  << A >>
> 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
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Thu, 2 Mar 2017 19:04:37 -0500
Links: << >>  << T >>  << A >>
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

Article: 159780
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Thu, 2 Mar 2017 19:14:13 -0500
Links: << >>  << T >>  << A >>
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

Article: 159781
Subject: Re: designing a fpga
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 03 Mar 2017 11:47:10 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 3 Mar 2017 08:52:18 -0800 (PST)
Links: << >>  << T >>  << A >>

> > 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
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Fri, 3 Mar 2017 11:57:50 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: designing a fpga
From: GaborSzakacs <gabor@alacron.com>
Date: Fri, 03 Mar 2017 13:58:28 -0500
Links: << >>  << T >>  << A >>
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: 159785
Subject: Re: designing a fpga
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 03 Mar 2017 14:42:52 -0600
Links: << >>  << T >>  << A >>
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

Article: 159786
Subject: Re: designing a fpga
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Fri, 3 Mar 2017 13:14:24 -0800
Links: << >>  << T >>  << A >>
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
Subject: temperature sense diodes in Xilinx 7 series
From: John Larkin <jjlarkinxyxy@highlandtechnology.com>
Date: Fri, 03 Mar 2017 13:34:58 -0800
Links: << >>  << T >>  << A >>
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.com


Article: 159788
Subject: Re: temperature sense diodes in Xilinx 7 series
From: John Larkin <jjlarkinxyxy@highlandtechnology.com>
Date: Fri, 03 Mar 2017 14:00:17 -0800
Links: << >>  << T >>  << A >>
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.com


Article: 159789
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Fri, 3 Mar 2017 17:02:53 -0500
Links: << >>  << T >>  << A >>
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: 159790
Subject: Re: designing a fpga
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 03 Mar 2017 17:33:43 -0600
Links: << >>  << T >>  << A >>
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

Article: 159791
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 3 Mar 2017 18:19:15 -0800 (PST)
Links: << >>  << T >>  << A >>
> 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
Subject: Re: designing a fpga
From: rickman <gnuarm@gmail.com>
Date: Fri, 3 Mar 2017 22:27:14 -0500
Links: << >>  << T >>  << A >>
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

Article: 159793
Subject: Re: temperature sense diodes in Xilinx 7 series
From: Allan Herriman <allanherriman@hotmail.com>
Date: 04 Mar 2017 10:52:06 GMT
Links: << >>  << T >>  << A >>
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

Article: 159794
Subject: Re: temperature sense diodes in Xilinx 7 series
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Sat, 04 Mar 2017 09:29:14 -0800
Links: << >>  << T >>  << A >>
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 electronics 


Article: 159795
Subject: Re: temperature sense diodes in Xilinx 7 series
From: Allan Herriman <allanherriman@hotmail.com>
Date: 05 Mar 2017 10:41:05 GMT
Links: << >>  << T >>  << A >>
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,
Allan

Article: 159796
Subject: Re: designing a fpga
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 07 Mar 2017 09:16:55 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 7 Mar 2017 12:08:34 -0800 (PST)
Links: << >>  << T >>  << A >>
> `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
Subject: Re: designing a fpga
From: GaborSzakacs <gabor@alacron.com>
Date: Tue, 07 Mar 2017 15:44:04 -0500
Links: << >>  << T >>  << A >>
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
Subject: Re: designing a fpga
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 7 Mar 2017 13:59:11 -0800 (PST)
Links: << >>  << T >>  << A >>
> 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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search