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 154550

Article: 154550
Subject: Re: Set-up and hold times and metastability
From: Jon Elson <jmelson@wustl.edu>
Date: Mon, 26 Nov 2012 16:20:20 -0600
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:


> The article http://www.technion.ac.il/~sbeer/publications/p3.pdf
> seems to have some pretty good data (actual numbers) on
> metastability.
Wow, this is an INTERESTING paper!  It definitely contradicts current
wisdom and extrapolation.  As FPGAs move to higher frequencies, this
trend is not good at all!

Jon

Article: 154551
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 27 Nov 2012 06:44:08 -0800 (PST)
Links: << >>  << T >>  << A >>
On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
> This is one of the reasons why I've never created a blog or other
> "expert" column on the web. =A0I may be fairly experienced, but by writin=
g
> things like this blog I may be showing what things I *don't* know rather
> than what I do... lol

I sign this statement ;)

Article: 154552
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Tue, 27 Nov 2012 07:10:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On 25 Nov., 20:11, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> In the following link, a design is presented that alledgedly
> has a flaw. The claim is that this is a simple case and
> that any experienced designer will see the flaw immediately.

If this code is from an experienced designer I see that much flaws,
that have no effect of synthesis or simulation itself, but on
readability.
The sensitivity list is horrible and will cause unnecessary simulator
load, the code indention is best effort to confuse readers. Some code
beautify would do better. And as simple as this design is, a real
world code without any comments is only good for protecting your
failures from reviewers.

The usage of integer as start value for a lfsr is quite error prone. A
hex value would be easier to read and would allow to design this
module without integer or unsigned values.
That clk_out is missing in reset path leads to one cycle latency of
rst to clk_out, that is most likely not intended here. But you could
only guess if that has impact on system or is even necessary.
If there is an abvious error in cycle lenght (be it start value or
feedback function), you can see this in simulation. I assume if you
use lfsr, you know that you should double check this, if you are not
really sure what you are doing.

bye Thomas


Article: 154553
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Tue, 27 Nov 2012 17:20:48 +0100
Links: << >>  << T >>  << A >>
On 11/25/2012 09:22 PM, Alan Fitch wrote:

> OK I cracked and read it.
>
> I don't really understand what's going on, I would have to simulate it
> (though of course you've already done that Jan!).

Yes.

> I agree there's something fishy about adding output delays. What
> difference would that make in this case?

According to me, none whatsoever. And that is also what I
see in my simulation.

The crazy thing is that he says he does see a difference,
in the sense that the version with delays "reveals the problem."
In particular, he claims that the output clock clk_out
never toggles in the version with delays, which is what
he says he sees on the FPGA also.

He includes waveforms and uses that observation to claim
that "the mystery has been solved".

But I see clk_out toggling correctly (as I would expect).
In particular, in my simulations it toggles at exactly
the same moments as in the version without delays.

The code has been posted on APP in ready-to-run format.
What is driving me crazy is that noone else on APP seems
to be interested in running it and confirming my results,
or not.

I'm not going to ask that from anybody here - you have helped
me enough already. Still, I include the code as it was posted
below, perhaps someone is interested anyway. (The test bench
as posted contains the design with the delays, and is ready
to run.)

Thanks,

Jan

----

First pass at code


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity lfsr_counter is
   port (
      rst, clk : in std_logic;
     clk_out : out std_logic);
end lfsr_counter;

architecture imp_lfsr_counter of lfsr_counter is	
   signal lfsr: std_logic_vector (13 downto 0);	
   signal d0, clk_i: std_logic;	
   constant countmax: integer:=2685;
begin

   d0 <= lfsr(13) xnor lfsr(4) xnor lfsr(2) xnor lfsr(0) ;

   process(clk,clk_i,lfsr,rst) begin
	
	  if rising_edge(clk) then
		   if rst='1' then
			  clk_i<='0';
			  lfsr <= (others=>'0');
		  else	 lfsr <= lfsr(12 downto 0) & d0;
     	  		if lfsr = std_logic_vector((TO_UNSIGNED(countmax,14))) then
       				clk_i<=not(clk_i);
				lfsr<=(others=>'0');
			end if;
		 end if;	
        	 	  clk_out<=clk_i;
   	  end if;
   end process;

  
end architecture imp_lfsr_counter;


---------------------------------------------------


So here is a very simple testbench :-

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity test_bench is
---there are no ports to declare so the entity is empty
end test_bench;

architecture behavioural of test_bench is
--call the device under test from the standard 'work' library
	component lfsr_counter_pd
		port  (
     			 rst, clk : in std_logic;
     			clk_out : out std_logic);
	end component;
--declare inputs and initialise them
signal clock_in : std_logic :='0';
signal reset    : std_logic :='0';
--declare outputs and initialise them
signal clock_out : std_logic:='0';
--clock period definition
constant clk_period : time :=10 ns;

begin

	--instantiate the unit under test
uut: lfsr_counter_pd port map (
			rst	=>	reset,
			clk	=>	clock_in,
			clk_out =>	clock_out);

        --generate the clock with 50% duty cycle
        -- this runs for ever it has no sensitivity list
clk_process : process
begin
	clock_in <='0';
	wait for clk_period/2;
	clock_in <='1';
	wait for clk_period/2;
end process;
--generate the stimulus for the unit under test

stim_process :process
begin
	wait for 100 ns;
	reset<='1';
	wait for clk_period * 2;
	reset <='0';
	wait;

end process;



end architecture behavioural;
	

--------------------------------------------------------

Another pass at the code


library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity lfsr_counter_pd is
   port (
      rst, clk : in std_logic;
     clk_out : out std_logic);
end lfsr_counter_pd;

architecture lfsr_counter of lfsr_counter_pd is	
   signal lfsr: std_logic_vector (13 downto 0);	
   signal d0, clk_i: std_logic;	
   constant countmax: integer:=2685;
   constant tpd     :time:=2 ns;
begin

  d0 <= lfsr(13) xnor lfsr(4) xnor lfsr(2) xnor lfsr(0) after tpd;

   process(clk,clk_i,lfsr,rst) begin
	
	  if rising_edge(clk) then
		   if rst='1' then
			  clk_i<='0';
			  lfsr <= (others=>'0') after tpd;
		  else	 lfsr <= lfsr(12 downto 0) & d0 after tpd;
		    if lfsr = std_logic_vector((TO_UNSIGNED(countmax,14))) then
       				clk_i<=not(clk_i)after tpd;
				lfsr<=(others=>'0') after tpd;
			end if;
		 end if;	
        	 	  clk_out<=clk_i;
   	  end if;
   end process;

  
end architecture lfsr_counter;


-----------------------------------------------------

Final pass at code

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity lfsr_counter is
   port (
      rst, clk : in std_logic;
     clk_out : out std_logic);
end lfsr_counter;

architecture lfsr_counter of lfsr_counteris	
   signal lfsr: std_logic_vector (13 downto 0);	
   signal d0, clk_i: std_logic;	
   constant countmax: integer:=2685;
   
begin

  
   process(clk,clk_i,lfsr,rst) begin
	
	  if rising_edge(clk) then
		   if rst='1' then
			  clk_i<='0';
			  lfsr <= (others=>'0') ;
		  else	 lfsr <= lfsr(12 downto 0) & d0;
		    d0 <= lfsr(13) xnor lfsr(4) xnor lfsr(2) xnor lfsr(0);
     	  		if lfsr = std_logic_vector((TO_UNSIGNED(countmax,14))) then
       				clk_i<=not(clk_i);
				lfsr<=(others=>'0') ;
			end if;
		 end if;	
        	 	  clk_out<=clk_i;
   	  end if;
   end process;

  
end architecture lfsr_counter;

----------





-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Article: 154554
Subject: Re: VHDL expert puzzle
From: Christopher Felton <nospam@nowhere.com>
Date: Tue, 27 Nov 2012 12:22:54 -0600
Links: << >>  << T >>  << A >>
<snip>
>
> I'm not going to ask that from anybody here - you have helped
> me enough already. Still, I include the code as it was posted
> below, perhaps someone is interested anyway. (The test bench
> as posted contains the design with the delays, and is ready
> to run.)
>
> Thanks,
>
> Jan
>

For giggles I ran the simulation, both are identical (except clock_out 
is delayed by tpd in the second).  The two waveforms he has in the post 
are not on the same "zoom".  The first is zoomed way out where you can 
see clock_out (solid for clock_in).  The second is zoomed way in where 
you can see the individual clock_in.

So, clock_out is probably toggling but he's not centered over an edge to 
actually view it.  If he used a self checking testbench he might have 
caught it (or rather not caught it) instead of relying on manually 
viewing the waveform.

Post should have been titled "Foiled by testbenches"?

Regards,
Chris

Article: 154555
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Tue, 27 Nov 2012 22:07:27 +0100
Links: << >>  << T >>  << A >>
On 11/27/2012 07:22 PM, Christopher Felton wrote:

> For giggles I ran the simulation, both are identical (except
> clock_out is delayed by tpd in the second).

Many thanks!

Mm, that holds for the intermediate clock signal clk_i, but
clk_out itself has no delay, correct?

>  The two waveforms he has
> in the post are not on the same "zoom".  The first is zoomed way out
> where you can see clock_out (solid for clock_in).  The second is
> zoomed way in where you can see the individual clock_in.
>
> So, clock_out is probably toggling but he's not centered over an edge
> to actually view it.

Could that be it? He wouldn't have bothered to do a full zoom first?
That would be such silly error that I admit I didn't consider it!

My hypothesis of initially faulty code would be consistent
with what he sees on the fpga.

Heck, perhaps I should just throw the towel. Noone on APP seems
to care.

> If he used a self checking testbench he might
> have caught it (or rather not caught it) instead of relying on
> manually viewing the waveform.

Of course. Actually, sometimes I think that if it's not
self-checking, it shouldn't be called a testbench.

It wouldn't be hard for a case like this (by checking edges,
you can verify whether the generated clock with some
frequence or period spec.)

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Article: 154556
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Wed, 28 Nov 2012 00:34:02 -0800 (PST)
Links: << >>  << T >>  << A >>
On 27 Nov., 17:20, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> The crazy thing is that he says he does see a difference,
> in the sense that the version with delays "reveals the problem."
> In particular, he claims that the output clock clk_out
> never toggles in the version with delays, which is what
> he says he sees on the FPGA also.
>
> He includes waveforms and uses that observation to claim
> that "the mystery has been solved".
>
> But I see clk_out toggling correctly (as I would expect).
> In particular, in my simulations it toggles at exactly
> the same moments as in the version without delays.

I advice using delays in general to help debuging code and to detect
inadverted clock-2-data race conditions when clock is going over
several signal assignments, but for me, this means, that I usually
only delay signal assignments from clock edge in clocked process, in
usual code thats enough to see, if data changes before or after clock
edge.

This particular code is no example, of code in which I expect delays
to matter (when using correct simulator).
I can only guess, that the simulator the author is using messes up
with this two lines

>   process(clk,clk_i,lfsr,rst) begin
>          if rising_edge(clk) then

and execute the code inside the if rising_edge clause also in delta
cycles that have no rising clock edge. In that case the trouble might
result from a mixture of unlucky sensitivity list with broken
simulator and missing delays and any one of the three can be used to
fix this issue.

bye Thomas

Article: 154557
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Wed, 28 Nov 2012 09:55:48 +0100
Links: << >>  << T >>  << A >>
On 11/28/2012 09:34 AM, Thomas Stanka wrote:
> On 27 Nov., 17:20, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>> The crazy thing is that he says he does see a difference,
>> in the sense that the version with delays "reveals the problem."
>> In particular, he claims that the output clock clk_out
>> never toggles in the version with delays, which is what
>> he says he sees on the FPGA also.
>>
>> He includes waveforms and uses that observation to claim
>> that "the mystery has been solved".
>>
>> But I see clk_out toggling correctly (as I would expect).
>> In particular, in my simulations it toggles at exactly
>> the same moments as in the version without delays.
>
> I advice using delays in general to help debuging code and to detect
> inadverted clock-2-data race conditions when clock is going over
> several signal assignments, but for me, this means, that I usually
> only delay signal assignments from clock edge in clocked process, in
> usual code thats enough to see, if data changes before or after clock
> edge.
>
> This particular code is no example, of code in which I expect delays
> to matter (when using correct simulator).
> I can only guess, that the simulator the author is using messes up
> with this two lines
>
>>    process(clk,clk_i,lfsr,rst) begin
>>           if rising_edge(clk) then
>
> and execute the code inside the if rising_edge clause also in delta
> cycles that have no rising clock edge.

A VHDL simulator broken in this way? Hard to imagine.


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Article: 154558
Subject: Re: VHDL expert puzzle
From: "kaz" <3619@embeddedrelated>
Date: Wed, 28 Nov 2012 03:17:44 -0600
Links: << >>  << T >>  << A >>

>
>I advice using delays in general to help debuging code and to detect
>inadverted clock-2-data race conditions when clock is going over
>several signal assignments, but for me, this means, that I usually
>only delay signal assignments from clock edge in clocked process, in
>usual code thats enough to see, if data changes before or after clock
>edge.
>
>bye Thomas
>

I can't understand your advice. For more than a decade I have used ModelSim
to
functionally verify chains of DSP modules and never needed to put any
delay
inside RTL code. In the top level testbench all inputs are generated on the

clocks so I wouldn't worry about delta delay problem.

Kaz


  	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 154559
Subject: Re: VHDL expert puzzle
From: Christopher Felton <nospam@nowhere.com>
Date: Wed, 28 Nov 2012 06:13:57 -0600
Links: << >>  << T >>  << A >>
On 11/27/2012 3:07 PM, Jan Decaluwe wrote:
> On 11/27/2012 07:22 PM, Christopher Felton wrote:
>
>> For giggles I ran the simulation, both are identical (except
>> clock_out is delayed by tpd in the second).
>
> Many thanks!
>
> Mm, that holds for the intermediate clock signal clk_i, but
> clk_out itself has no delay, correct?
>
Correct, I misstated.  Only the internal nets will see the added delay.

>>  The two waveforms he has
>> in the post are not on the same "zoom".  The first is zoomed way out
>> where you can see clock_out (solid for clock_in).  The second is
>> zoomed way in where you can see the individual clock_in.
>>
>> So, clock_out is probably toggling but he's not centered over an edge
>> to actually view it.
>
> Could that be it? He wouldn't have bothered to do a full zoom first?
> That would be such silly error that I admit I didn't consider it!
>
> My hypothesis of initially faulty code would be consistent
> with what he sees on the fpga.

I think your hypothesis is correct; we are missing part of the story. 
Either the code is not the original code, he had some other error in the 
process, or he ignored the timing reports and the second run he just 
happened to meet timing.  To your point, if he runs syn+P&R again, it 
might fail.  Nothing solved or fixed.


>
> Heck, perhaps I should just throw the towel. Noone on APP seems
> to care.
>

Which is odd, they should care.  In my mind that is the beauty of a 
technical *community*, in the end you get a much better result.  This is 
a perfect example, his goal was to show simulating/testing can be 
beneficial.  But his example *failed* to prove the point.  To the rescue 
the community ... except the author didn't want to participate?

In general this is bad, because the correct feedback is available to the 
author and it is not being fixed.  Hopefully, the poor quality will will 
only reflect on the author and not APP's reputations.  And yes, it 
doesn't seem like any progress is being made, what's the saying, the 
advice is falling on deaf ears.

>> If he used a self checking testbench he might
>> have caught it (or rather not caught it) instead of relying on
>> manually viewing the waveform.
>
> Of course. Actually, sometimes I think that if it's not
> self-checking, it shouldn't be called a testbench.

wiggle_bench

>
> It wouldn't be hard for a case like this (by checking edges,
> you can verify whether the generated clock with some
> frequence or period spec.)
>
> Jan
>


Article: 154560
Subject: Re: VHDL expert puzzle
From: Christopher Felton <nospam@nowhere.com>
Date: Wed, 28 Nov 2012 06:22:04 -0600
Links: << >>  << T >>  << A >>
On 11/28/2012 3:17 AM, kaz wrote:
>>
>> I advice using delays in general to help debuging code and to detect
>> inadverted clock-2-data race conditions when clock is going over
>> several signal assignments, but for me, this means, that I usually
>> only delay signal assignments from clock edge in clocked process, in
>> usual code thats enough to see, if data changes before or after clock
>> edge.
>>
>> bye Thomas
>>
>
> I can't understand your advice. For more than a decade I have used ModelSim
> to
> functionally verify chains of DSP modules and never needed to put any
> delay
> inside RTL code. In the top level testbench all inputs are generated on the
>
> clocks so I wouldn't worry about delta delay problem.
>
> Kaz
>
>

I agree, I don't like and would not advocate adding these type of delays 
to behavioral simulations.  If you want a more "physical" simulation 
there are other methods.  If you don't trust the static timing analysis 
you can simulate gate-level structural simulation with back-annotated 
timing information.  You can do this with an FPGA and the FPGA tools. 
But this is usually not done because we typically are ok with the static 
timing results and then take it to the lab, for an FPGA.

Regards,
Chris


Article: 154561
Subject: Re: VHDL expert puzzle
From: Mike Perkins <spam@spam.com>
Date: Wed, 28 Nov 2012 13:15:53 +0000
Links: << >>  << T >>  << A >>
On 27/11/2012 14:44, Thomas Stanka wrote:
> On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
>> This is one of the reasons why I've never created a blog or other
>> "expert" column on the web.  I may be fairly experienced, but by writing
>> things like this blog I may be showing what things I *don't* know rather
>> than what I do... lol
>
> I sign this statement ;)
>

I would agree to this further.  For this puzzle, some vendor 
synthesisers have treated sensitivity lists differently and made 
different assumptions to complicate things still further.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 154562
Subject: Re: VHDL expert puzzle
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Wed, 28 Nov 2012 13:20:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 28 Nov 2012 03:17:44 -0600, kaz wrote:


>>I advice using delays in general to help debuging code and to detect
>>inadverted clock-2-data race conditions when clock is going over several
>>signal assignments, but for me, this means, that I usually only delay
>>signal assignments from clock edge in clocked process, in usual code
>>thats enough to see, if data changes before or after clock edge.
>>
> I can't understand your advice. For more than a decade I have used
> ModelSim to functionally verify chains of DSP modules and never needed
> to put any delay inside RTL code. In the top level testbench all inputs
> are generated on the 
> clocks so I wouldn't worry about delta delay problem.

I have sometimes had to put delays on I/O signals between my FPGA and 
vendor-supplied models, e.g. for memory devices, to make a board level 
behavioural simulation match the real world. 
If I didn't, data would appear a cycle early, or be written to an off-by-
one address, or the "data stable" eye would miss my sampling point, etc.

I think this is justifiable as making the FPGA model more closely match 
its real world behaviour, but I have never had to do the same internally!

- Brian

Article: 154563
Subject: Re: VHDL expert puzzle
From: Jan Decaluwe <jan@jandecaluwe.com>
Date: Wed, 28 Nov 2012 14:47:32 +0100
Links: << >>  << T >>  << A >>
On 11/28/2012 02:15 PM, Mike Perkins wrote:
> On 27/11/2012 14:44, Thomas Stanka wrote:
>> On 26 Nov., 19:14, rickman <gnu...@gmail.com> wrote:
>>> This is one of the reasons why I've never created a blog or
>>> other "expert" column on the web.  I may be fairly experienced,
>>> but by writing things like this blog I may be showing what things
>>> I *don't* know rather than what I do... lol
>>
>> I sign this statement ;)
>>
>
> I would agree to this further.  For this puzzle, some vendor
> synthesisers have treated sensitivity lists differently and made
> different assumptions to complicate things still further.

There a issues at multiple levels with this. However
a major one has only to do with modeling and simulation,
namely whether adding the delays should make a difference
to the behavior of the clock output (as he claims),
or not (which is what we see and expect).

Any standard VHDL simulator should give the same answer here.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Article: 154564
Subject: Re: VHDL expert puzzle
From: Michael S <already5chosen@yahoo.com>
Date: Wed, 28 Nov 2012 07:46:30 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 25, 9:11=A0pm, Jan Decaluwe <j...@jandecaluwe.com> wrote:
> In the following link, a design is presented that alledgedly
> has a flaw. The claim is that this is a simple case and
> that any experienced designer will see the flaw immediately.
>
> (I don't.)
>
> http://www.programmableplanet.com/author.asp?section_id=3D2551&doc_id=3D2=
...
>
> --
> Jan Decaluwe - Resources bvba -http://www.jandecaluwe.com
> =A0 =A0 =A0Python as a HDL:http://www.myhdl.org
> =A0 =A0 =A0VHDL development, the modern way:http://www.sigasi.com
> =A0 =A0 =A0World-class digital design:http://www.easics.com

An original code is o.k. except for bad style, as mentioned by just
about everybody above, and for kludgy idea to use MLSR to divide
clock.
At least what's implemented is real 14-bit MLSR with period =3D 2^14-1.
It appears to divide the input clock by 24998 and that's supposedly
was an original intention. Or did he tried to divide by 25000? Or, may
be he really divides by 25000 and I miscalculated by one somewhere?
Anyway, it's pretty close :-)

A "fixed" code is much worse.
It, supposedly unintentionally, implements 15-bit LSR with
period=3D7905, i.e. *not* MLSR. Input clock is divided by 11684. It's
sounds damn unlikely that that was an intention.



Article: 154565
Subject: Re: VHDL expert puzzle
From: Michael S <already5chosen@yahoo.com>
Date: Wed, 28 Nov 2012 07:50:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 27, 5:10=A0pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:
> On 25 Nov., 20:11, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
> > In the following link, a design is presented that alledgedly
> > has a flaw. The claim is that this is a simple case and
> > that any experienced designer will see the flaw immediately.
>
> If this code is from an experienced designer I see that much flaws,
> that have no effect of synthesis or simulation itself, but on
> readability.
> The sensitivity list is horrible and will cause unnecessary simulator
> load, the code indention is best effort to confuse readers. Some code
> beautify would do better. And as simple as this design is, a real
> world code without any comments is only good for protecting your
> failures from reviewers.
>
> The usage of integer as start value for a lfsr is quite error prone. A
> hex value would be easier to read and would allow to design this
> module without integer or unsigned values.

On this one, and only this one, I disagree.

> That clk_out is missing in reset path leads to one cycle latency of
> rst to clk_out, that is most likely not intended here. But you could
> only guess if that has impact on system or is even necessary.


I also don't like naming synchronous reset 'rst'. I'd rather prefere
'srst" or 'sreset'.

> If there is an abvious error in cycle lenght (be it start value or
> feedback function), you can see this in simulation. I assume if you
> use lfsr, you know that you should double check this, if you are not
> really sure what you are doing.
>
> bye Thomas

Just about everything he wrote on the second page makes no sense.

Article: 154566
Subject: Re: VHDL expert puzzle
From: Michael S <already5chosen@yahoo.com>
Date: Wed, 28 Nov 2012 07:55:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 28, 5:50=A0pm, Michael S <already5cho...@yahoo.com> wrote:
> On Nov 27, 5:10=A0pm, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
> wrote:
>
>
>
>
>
>
>
>
>
> > On 25 Nov., 20:11, Jan Decaluwe <j...@jandecaluwe.com> wrote:
>
> > > In the following link, a design is presented that alledgedly
> > > has a flaw. The claim is that this is a simple case and
> > > that any experienced designer will see the flaw immediately.
>
> > If this code is from an experienced designer I see that much flaws,
> > that have no effect of synthesis or simulation itself, but on
> > readability.
> > The sensitivity list is horrible and will cause unnecessary simulator
> > load, the code indention is best effort to confuse readers. Some code
> > beautify would do better. And as simple as this design is, a real
> > world code without any comments is only good for protecting your
> > failures from reviewers.
>
> > The usage of integer as start value for a lfsr is quite error prone. A
> > hex value would be easier to read and would allow to design this
> > module without integer or unsigned values.
>
> On this one, and only this one, I disagree.
>
> > That clk_out is missing in reset path leads to one cycle latency of
> > rst to clk_out, that is most likely not intended here. But you could
> > only guess if that has impact on system or is even necessary.
>
> I also don't like naming synchronous reset 'rst'. I'd rather prefere
> 'srst" or 'sreset'.
>
> > If there is an abvious error in cycle lenght (be it start value or
> > feedback function), you can see this in simulation. I assume if you
> > use lfsr, you know that you should double check this, if you are not
> > really sure what you are doing.
>
> > bye Thomas
>
> Just about everything he wrote on the second page makes no sense.

Oh, another style flow is xnor.
The only valid use of xnor is when you want to obfuscate your
intentions.

Article: 154567
Subject: Re: VHDL expert puzzle
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Wed, 28 Nov 2012 09:01:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On 28 Nov., 10:17, "kaz" <3619@embeddedrelated> wrote:
> >I advice using delays in general to help debuging code and to detect
> >inadverted clock-2-data race conditions when clock is going over
> >several signal assignments, but for me, this means, that I usually
> >only delay signal assignments from clock edge in clocked process, in
> >usual code thats enough to see, if data changes before or after clock
> >edge.
>
> I can't understand your advice. For more than a decade I have used ModelSim
> to
> functionally verify chains of DSP modules and never needed to put any
> delay
> inside RTL code. In the top level testbench all inputs are generated on the
>
> clocks so I wouldn't worry about delta delay problem.

In DSP I guess you have in general only one clk and all modules
synchonous.

Consider a larger design using IP (and maybe several clock with some
relation).
the following construct might be hidden within some IP most likley
over hierarchy boundaries and more difficult to detect.

Clk1 <= Clk when Selected else Other_Clk';
[..]
Clk2 <= Clk1 when Enabled else '0';
[..]
process (Clk)
  if rising_edge(Clk) then
     A <= B;
[..]
process (Clk2)
  if rising_edge(Clk2)
     B<= A;

Clk2 changes 2 delta after Clk, therefore in simulation registers A
and B won't exchange their value every clock cycle, instead  both
registers will have same content after rising edge while the code is
written in a correct way. Have fun debugging why simulation is not
working as expected in such a case.

With the same mechanism you could create examples where simulation
without delay is correct, but HW after Synthesis wrong in which case a
delay would have helped you detecting it faster in waveform.

bye Thomas




Article: 154568
Subject: Re: VHDL expert puzzle
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 28 Nov 2012 17:43:38 -0800 (PST)
Links: << >>  << T >>  << A >>
Actually your example does not quite demonstrate the point you were making.=
  In your example, you have actual function (the muxing and enabling) betwe=
en the clocks so you're describing a gated clock system.  That system, if b=
uilt, could very well behave exactly as you have described but not be what =
the designer intended simply because the designer did not account for the c=
lock skew.  The simulation without the added delay very well may describe t=
he actual hardware.  In this case, adding the delay 'to fix the simulation'=
 would be sweeping the design error under the rug until it eventually is un=
covered in real hardware.

To demonstrate your point though you simply need to generate the new clock =
as this:

clk1 <=3D clk;

Then clock things with 'clk' and 'clk1' and watch them not work.  In this i=
nstance the 'clk1 <=3D clk;' assignment would not be implemented in any har=
dware but the simulator would be off by a delta cycle.

Kevin Jennings

Article: 154569
Subject: Re: VHDL expert puzzle
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Thu, 29 Nov 2012 09:51:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
On Wed, 28 Nov 2012 17:43:38 -0800, KJ wrote:

> clk1 <= clk;
> 
> Then clock things with 'clk' and 'clk1' and watch them not work.  In
> this instance the 'clk1 <= clk;' assignment would not be implemented in
> any hardware but the simulator would be off by a delta cycle.
> 
> Kevin Jennings

Even funnier when the clock assignment is helpfully implemented for you, 
in a vendor's memory module...

- Brian


Article: 154570
Subject: Re: VHDL expert puzzle
From: Allan Herriman <allanherriman@hotmail.com>
Date: 29 Nov 2012 13:22:12 GMT
Links: << >>  << T >>  << A >>
On Wed, 28 Nov 2012 13:20:14 +0000, Brian Drummond wrote:

> On Wed, 28 Nov 2012 03:17:44 -0600, kaz wrote:
> 
> 
>>>I advice using delays in general to help debuging code and to detect
>>>inadverted clock-2-data race conditions when clock is going over
>>>several signal assignments, but for me, this means, that I usually only
>>>delay signal assignments from clock edge in clocked process, in usual
>>>code thats enough to see, if data changes before or after clock edge.
>>>
>> I can't understand your advice. For more than a decade I have used
>> ModelSim to functionally verify chains of DSP modules and never needed
>> to put any delay inside RTL code. In the top level testbench all inputs
>> are generated on the clocks so I wouldn't worry about delta delay
>> problem.
> 
> I have sometimes had to put delays on I/O signals between my FPGA and
> vendor-supplied models, e.g. for memory devices, to make a board level
> behavioural simulation match the real world.
> If I didn't, data would appear a cycle early, or be written to an
> off-by-
> one address, or the "data stable" eye would miss my sampling point, etc.
> 
> I think this is justifiable as making the FPGA model more closely match
> its real world behaviour, but I have never had to do the same
> internally!


I've had to put (simulation-only) delays on internal signals.

There was one version of Xilinx's block ram in their Verilog unisim 
library that was broken.  IIRC, the bug had something to do with a delay 
on the clock inside the unisim model.

Synthesis was fine, but it didn't give the right result in simulation 
until I modified my source code to add a delay on the signals feeding the 
ram.

I think it might have been the version of unisim that came with ISE 10.1.


Regards,
Allan

Article: 154571
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Nov 2012 09:22:12 -0500
Links: << >>  << T >>  << A >>
On 11/28/2012 10:50 AM, Michael S wrote:
> On Nov 27, 5:10 pm, Thomas Stanka<usenet_nospam_va...@stanka-web.de>
> wrote:
>> The usage of integer as start value for a lfsr is quite error prone. A
>> hex value would be easier to read and would allow to design this
>> module without integer or unsigned values.
>
> On this one, and only this one, I disagree.

I had a bit of confusion on this one myself.  Not that he was using an 
integer per-se, but that he didn't explain in a comment why this value 
was important or how it was derived.  I had to consider that this value 
was ill-conceived and didn't want to bother with looking up the LFSR and 
calculating where this value would appear in the sequence, etc.  It 
would have been useful if he had added a comment saying the length of 
the loop is xxx clocks or yyy time.


>> That clk_out is missing in reset path leads to one cycle latency of
>> rst to clk_out, that is most likely not intended here. But you could
>> only guess if that has impact on system or is even necessary.
>
>
> I also don't like naming synchronous reset 'rst'. I'd rather prefere
> 'srst" or 'sreset'.

I think for FPGAs it is very common to specify an async reset to assign 
the configuration value of each FF, so I have come to expect async 
resets.  But if they use a sync reset, it doesn't bother me.  I don't 
expect that aspect of the reset to be part of the name.  I think resets 
are complex enough that they should be designed and documented at the 
system level.


>> If there is an abvious error in cycle lenght (be it start value or
>> feedback function), you can see this in simulation. I assume if you
>> use lfsr, you know that you should double check this, if you are not
>> really sure what you are doing.
>>
>> bye Thomas
>
> Just about everything he wrote on the second page makes no sense.

Yes, I'm not sure what he was thinking.  It is a bit funny how he 
responds to this in the blog.  He starts out discussing it a little 
defensively and after three or four rounds of increasing defensiveness 
on his side he says something like, "Just forget about it".  I expect it 
was a bit embarrassing to make a mistake so publicly.  I'm sure we have 
all made similar mistakes, the kind where we slap the side of our head 
and say, "what was I thinking?"  But to do it publicly is a different 
matter.

I think the "Just forget about it" comment was on the second page of 
comments and there were six when I read it.  So I guess he is getting 
beat up pretty badly.  I feel for him.

Rick

Article: 154572
Subject: Re: VHDL expert puzzle
From: rickman <gnuarm@gmail.com>
Date: Thu, 29 Nov 2012 09:26:08 -0500
Links: << >>  << T >>  << A >>
On 11/28/2012 10:55 AM, Michael S wrote:
>
> Oh, another style flow is xnor.
> The only valid use of xnor is when you want to obfuscate your
> intentions.

I don't understand.  What would you use in place of xnor?  In LFSRs 
there are two ways of coding them.  Using the XOR function creates two 
loops, one being the all zeros state.  Using the XNOR function creates 
two loops, one being the all ones state.  What is wrong with using the 
XNOR function to describe a LFSR with the all ones state as the excluded 
state?

Rick

Article: 154573
Subject: Re: VHDL expert puzzle
From: "Kerry Imming" <kcimming@pobox.com>
Date: Thu, 29 Nov 2012 08:50:23 -0600
Links: << >>  << T >>  << A >>

"rickman" <gnuarm@gmail.com> wrote in message 
news:k97ral$oin$1@dont-email.me...
> On 11/28/2012 10:55 AM, Michael S wrote:
>>
>> Oh, another style flow is xnor.
>> The only valid use of xnor is when you want to obfuscate your
>> intentions.
>
> I don't understand.  What would you use in place of xnor?  In LFSRs there 
> are two ways of coding them.  Using the XOR function creates two loops, 
> one being the all zeros state.  Using the XNOR function creates two loops, 
> one being the all ones state.  What is wrong with using the XNOR function 
> to describe a LFSR with the all ones state as the excluded state?

I think the problem is not the LFSR, but that the XNOR operation can be 
non-intuitive.

For example:   a XNOR b XNOR c  is equivalent to a XOR b XOR c
Since there is an even number of inversions, the inversions cancel out.
In the given example, there is an odd number of XNORs, so it works as 
written.

My preferred style would be.    d <= NOT (a XOR b XOR c);

- Kerry



Article: 154574
Subject: Re: VHDL expert puzzle
From: Michael S <already5chosen@yahoo.com>
Date: Thu, 29 Nov 2012 07:28:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Nov 29, 4:50=A0pm, "Kerry Imming" <kcimm...@pobox.com> wrote:
>
> I think the problem is not the LFSR, but that the XNOR operation can be
> non-intuitive.
>
> For example: =A0 a XNOR b XNOR c =A0is equivalent to a XOR b XOR c
> Since there is an even number of inversions, the inversions cancel out.
> In the given example, there is an odd number of XNORs, so it works as
> written.
>
> My preferred style would be. =A0 =A0d <=3D NOT (a XOR b XOR c);
>
> - Kerry

Yes, that's exactly what I meant to say.




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