EDK : FSL macros defined by Xilinx are wrong

[Carl]

I agree Andy - making this into a function makes the code cleaner and
is preferred if I would use this more than once.

 

[Andy]

On May 13, 1:40 pm, Carl <carw...@gmail.com> wrote:

I agree Andy - making this into a function makes the code cleaner and
is preferred if I would use this more than once.

Carl,

I would encourage you and others to think about what "use this code
more than once" means...

Anyone reviewing the code? Anyone maintaining the code? In this
context, "anyone" can be even be you, 6 weeks, 6 months or 6 years
after you wrote it. For myself, I could include "6 days" too!

Clean code is easier to understand for everyone. Good comments help,
but well written code, with appropriately named entities, functions,
procedures, variables, and signals, helps a lot more.

For example byte_vector may be too general a name in some cases. Is
the byte vector organized as little endian or big endian? Are both
kinds used in the same environment? perhaps big_endian and/or
little_endian are better names for the type. The to_unsigned()
function could be overridden for each type appropriately. And
naturally, to_big_endian(), etc. written as well.

Something to think about...

OK, I'm stepping off my soapbox now...

Andy

 

[kaz]

Haven't looked well but about the only unusual thing is the sensitivit
list and the the author's explanation which is wrong. D0 is synchronise
because it is dependent on lfsr bits. The author should say that he neede
one clock latency functionally on D0 instead.

Kaz

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

 

[kaz]

The big flaw is the combinatorial feedback of bit 0. since d0 <
xnor...bit0
and bit0 is assigned do.

Kaz

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

 

[kaz]

The big flaw is the combinatorial feedback of bit 0. since d0 <=
xnor...bit0
and bit0 is assigned do.

Kaz

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

sorry correcting myself: there is one register between bit0 and d0.
I believe the author has wrong observation.
if simulation worked it should work in hardware.
The fact that it didn't then it worked by moving d0 to clocked process i
fishy.

Kaz

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

 

[kaz]

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 ModelSi
to
functionally verify chains of DSP modules and never needed to put an
delay
inside RTL code. In the top level testbench all inputs are generated on th

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

Kaz




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

 

[Christopher Felton]

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

 

[Brian Drummond]

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

 

[Thomas Stanka]

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

 

[KJ]

Actually your example does not quite demonstrate the point you were making. In your example, you have actual function (the muxing and enabling) between the clocks so you're describing a gated clock system. That system, if built, 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 clock skew. The simulation without the added delay very well may describe the 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 uncovered in real hardware.

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

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

 

[Brian Drummond]

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

 

[Allan Herriman]

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

 

[KJ]

On Thursday, November 29, 2012 2:30:50 PM UTC-5, Jan Decaluwe wrote:

Why is this an issue?

It's not an issue. I was only pointing out that there is no need
for you "to feel for him" (For full disclosure and
information only: it is actually an issue for me personally

But now you're letting this guy's postings bother you so much that the two sentences you just wrote contradict each other.

- since some time I am also a blogger on APP and I have spent
lots of time trying to write high quality blogs. That makes
little sense if it turns out you can write anything you want
without having to worry about correctness.)

I don't follow how you think it makes no sense for you to write high quality blogs alongside someone who you (and apparently others) think writes low quality ones. If APP has no editorial board or peer review process (which is what it looks like to me), then there is no quality control mechanism other than the replies to the blog. So you can't choose your fellow bloggers....but you can control that by blogging elsewhere if you so choose.

It seems to me that you took what probably looked to you at first to be an 'interesting' problem and found that the author had (to be polite) a few errors and that it was just a dud rather than something interesting. Maybe you're put off by the time you invested in it...you seem to have taken offense that the author basically blew it all off rather than taking the postings as useful corrective feedback. So what? Don't make it any sort of personal (or non-personal) issue to you since that is something you can control.

Kevin Jennings

 

[Jan Decaluwe]

On 11/30/2012 03:40 AM, KJ wrote:

On Thursday, November 29, 2012 2:30:50 PM UTC-5, Jan Decaluwe wrote:
Why is this an issue?

It's not an issue. I was only pointing out that there is no need
for you "to feel for him" (For full disclosure and information
only: it is actually an issue for me personally

But now you're letting this guy's postings bother you so much that
the two sentences you just wrote contradict each other.

It's a personal issue for me, but it shouldn't become one for
anybody else here. I was looking for technical feedback and
confirmation of my findings, and I got it.

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

 

[Jan Decaluwe]

On 11/30/2012 03:40 AM, KJ wrote:

I don't follow how you think it makes no sense for you to write high
quality blogs alongside someone who you (and apparently others) think
writes low quality ones. If APP has no editorial board or peer
review process (which is what it looks like to me), then there is no
quality control mechanism other than the replies to the blog.

From those replies (or lack of replies) I infer, perhaps
incorrectly, whether I have an audience myself. If there's no
interest or support to correct even the most basic and flagrant
errors, I admit that I have some doubts.

So you can't choose your fellow bloggers...but you can control that by
blogging elsewhere if you so choose.

Correct. So the question I have to answer for myself is whether
APP is giving me the short-term added value (a large interested
audience) that I thought it would give me. The site has significant
disadvangages too: it's hard to find old posts back, and the
comment section's threading mechanism doesn't work well.

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

 

[Thomas Stanka]

On 29 Nov., 02:43, KJ <kkjenni...@sbcglobal.net> wrote:

Actually your example does not quite demonstrate the point you were making.  In your example, you have actual function (the muxing and enabling) between the clocks so you're describing a gated clock system.  That system, if built, 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 clock skew.  The simulation without the added delay very well may describe the 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 uncovered in real hardware.

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

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.

You are right, that clock gateing might destory a bit the story, but
in general clock skew is handled during layout and checked by STA.
During simulation of rtl code I have to assume, that layout does not
destroy my functionality, otherwise I could stop simualtion anyway.

regards Thomas

 

[rickman]

On 11/30/2012 4:05 AM, Thomas Stanka wrote:

You are right, that clock gateing might destory a bit the story, but
in general clock skew is handled during layout and checked by STA.
During simulation of rtl code I have to assume, that layout does not
destroy my functionality, otherwise I could stop simualtion anyway.

regards Thomas

My understanding is that logic delays in FPGAs are always longer than
clock delays on the clock trees so that you can't have a hold time
violation. If the clock is routed on the signal routing then all bets
are off. I don't know how well the timing analysis does with verifying
clock delays on the signal routing because I have never needed to use it
that I can remember.

Rick

 

[kaz]

On 11/30/2012 12:55 AM, Bart Fox wrote:
rickman wrote:

I have no idea why you say an async reset won't work in a sync design.
Do I misunderstand your statement? I am talking about FPGAs where every
chip has an async reset during configuration. You can choose to use
this in your design or not, but it is there and it works no matter what
you do. I supposed I should have qualified my statement to FPGAs that
use RAM configuration and have to be configured. There aren't a lot of
true flash based device that come up instantly without a configuration
process.

Rick

Indeed. Altera recommends using the reset async port but with sync signa
pre-synchronised. Xilinx, I believe, recommends using synchronous sync. Bu
again we need to be careful about our wording. Synchronous sync is actuall
applied to input D through logic and does not mean necessarily it i
pre-synchronised. Whether you name it async or sync, the signal be defaul
is not pre-synchronised and for sake of timing at release, they have to b
generated from flip's clock domain before applying it.

With today's large designs I prefer not to apply reset unless absolutel
needed. I know many of us will apply it as routine to masses of buses a
every node but I believe it puts massive burden on fitter to mee
removal/recovery timing when such effort better be directed somewhere mor
critical.

Kaz

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

 

[kaz]

On 11/30/2012 12:55 AM, Bart Fox wrote:
rickman wrote:

I have no idea why you say an async reset won't work in a sync design.
Do I misunderstand your statement? I am talking about FPGAs where ever

chip has an async reset during configuration. You can choose to use
this in your design or not, but it is there and it works no matter what
you do. I supposed I should have qualified my statement to FPGAs that
use RAM configuration and have to be configured. There aren't a lot of
true flash based device that come up instantly without a configuration
process.

Rick


Indeed. Altera recommends using the reset async port but with sync signal

pre-synchronised. Xilinx, I believe, recommends using synchronous sync
But
again we need to be careful about our wording. Synchronous sync i
actually
applied to input D through logic and does not mean necessarily it is
pre-synchronised. Whether you name it async or sync, the signal be default
is not pre-synchronised and for sake of timing at release, they have to be
generated from flip's clock domain before applying it.

With today's large designs I prefer not to apply reset unless absolutely
needed. I know many of us will apply it as routine to masses of buses at
every node but I believe it puts massive burden on fitter to meet
removal/recovery timing when such effort better be directed somewhere more
critical.

Note also the resource difference between the case of using async port(jus

routing) and sync reset(logic).

Kaz



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

 

[KJ]

On 11/30/2012 4:05 AM, Thomas Stanka wrote:
You are right, that clock gateing might destory a bit the
story, but in general clock skew is handled during layout and
checked by STA. During simulation of rtl code I have to assume,
that layout does not destroy my functionality, otherwise I
could stop simualtion anyway.

Short of required hand placement, there is no way to 'handle' clock skew in layout in an FPGA/CPLD. Logic induced skew between any two clocks creates two clock domains. If the design is such that the two clocks are treated as unrelated (for example if data only moves from one domain to the other through a dual clock fifo) then the design will work. You might get lucky, you might not if you think that any place and route tool will help you out here. Most likely you will encounter the 'bad' sort of luck, not the 'good luck'.

On Friday, November 30, 2012 3:07:17 PM UTC-5, rickman wrote:
My understanding is that logic delays in FPGAs are always longer
than clock delays on the clock trees so that you can't have a
hold time violation. If the clock is routed on the signal routing
then all bets are off. I don't know how well the timing analysis
does with verifying clock delays on the signal routing because I
have never needed to use it that I can remember

It doesn't need to depend on routing. Thomas' example introduced a logic delay between the two clocks. The implementation of that logic will create a race condition.

Kevin Jennings