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
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! JonArticle: 154551
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
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 ThomasArticle: 154553
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<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, ChrisArticle: 154555
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: 154556On 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 ThomasArticle: 154557
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> >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.comArticle: 154559
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
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, ChrisArticle: 154561
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.ukArticle: 154562
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! - BrianArticle: 154563
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: 154564On 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
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
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
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: 154568Actually 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 JenningsArticle: 154569
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... - BrianArticle: 154570
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, AllanArticle: 154571
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. RickArticle: 154572
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? RickArticle: 154573
"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); - KerryArticle: 154574
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:
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