need a cheap student edition FPGA

[Allan Herriman]

On Tue, 28 Jul 2009 15:22:25 +0000, Allan Herriman wrote:

On Sun, 26 Jul 2009 10:28:03 -0700, Muzaffer Kal wrote:

On 26 Jul 2009 16:23:16 GMT, General Schvantzkoph
schvantzkoph@yahoo.com> wrote:

Has anyone benchmarked Core7 vs Core2 on NCverilog, Questa, Xilinx and
Altera FPGA tools?

I'd also be very interested in Core7 vs Phenom II performance too (45nm
AMD ie Phenom II 955 etc.)


We just got a new i7 machine for FPGA builds. It tested at just over
twice as fast as our high-end AMD box that was 2-3 years old.

I will publish the results in this ng within a week or two, assuming I
can ever get the licensing for ISE 11.2 running on it. (Thanks Xilinx,
flexlm was a really good move.)

It's been a week and we still can't get the Xilinx licensing working on
the new machine, so I can't post any ISE11.2 results. I assume we will
be able to get the licensing running soon, because I have told the local
Xilinx reps that I won't be designing their parts into new products if we
can't run the software. My last big design used an Altera FPGA, so they
know I'm not joking.

Here are the two machines:

Old machine:
AMD Phenom 9750 CPU 2.40GHz
MSI K9A2-CD-F Motherboard (AMD 790X Chipset)
8GB Corsair TWIN2X2048-8500C5DF Xtreme CL5 DDR2 RAM (1066MHz)
Windows XP Professional x64 Edition Version 2003 Service Pack 2

New machine:
Intel Core i7 Extreme Edition 975 CPU 3.33GHz
Asus Rampage-II-Extreme Motherboard (Intel X58 Chipset)
12GB OCZ Platinum Low-Voltage Triple Channel CL7 DDR3 RAM (1600MHz),
Windows Server 2003 R2 Standard x64 Edition Service Pack 2.


Using ISE8.2 SP3 (yes, 8.2) on an old test design that almost filled a
medium sized fpga, we recorded a run time of 6 hours and 12 minutes for
the older AMD machine, and 3 hours and 3 minutes for the new i7 machine.
That's 2.03 times as fast.

The runs contained XST, ngdbuild, map, par, etc.
In both cases, the 32 bit version of software was used. Peak memory
usage (during map) was just under 3GBytes.
Map was run with the -speed option.

Regards,
Allan

 

[General Schvantzkoph]

On Thu, 06 Aug 2009 14:21:34 +0000, Allan Herriman wrote:

On Tue, 28 Jul 2009 15:22:25 +0000, Allan Herriman wrote:

On Sun, 26 Jul 2009 10:28:03 -0700, Muzaffer Kal wrote:

On 26 Jul 2009 16:23:16 GMT, General Schvantzkoph
schvantzkoph@yahoo.com> wrote:

Has anyone benchmarked Core7 vs Core2 on NCverilog, Questa, Xilinx and
Altera FPGA tools?

I'd also be very interested in Core7 vs Phenom II performance too
(45nm AMD ie Phenom II 955 etc.)


We just got a new i7 machine for FPGA builds. It tested at just over
twice as fast as our high-end AMD box that was 2-3 years old.

I will publish the results in this ng within a week or two, assuming I
can ever get the licensing for ISE 11.2 running on it. (Thanks Xilinx,
flexlm was a really good move.)


It's been a week and we still can't get the Xilinx licensing working on
the new machine, so I can't post any ISE11.2 results. I assume we will
be able to get the licensing running soon, because I have told the local
Xilinx reps that I won't be designing their parts into new products if
we can't run the software. My last big design used an Altera FPGA, so
they know I'm not joking.

Here are the two machines:

Old machine:
AMD Phenom 9750 CPU 2.40GHz
MSI K9A2-CD-F Motherboard (AMD 790X Chipset) 8GB Corsair
TWIN2X2048-8500C5DF Xtreme CL5 DDR2 RAM (1066MHz) Windows XP
Professional x64 Edition Version 2003 Service Pack 2

New machine:
Intel Core i7 Extreme Edition 975 CPU 3.33GHz Asus Rampage-II-Extreme
Motherboard (Intel X58 Chipset) 12GB OCZ Platinum Low-Voltage Triple
Channel CL7 DDR3 RAM (1600MHz), Windows Server 2003 R2 Standard x64
Edition Service Pack 2.


Using ISE8.2 SP3 (yes, 8.2) on an old test design that almost filled a
medium sized fpga, we recorded a run time of 6 hours and 12 minutes for
the older AMD machine, and 3 hours and 3 minutes for the new i7 machine.
That's 2.03 times as fast.

The runs contained XST, ngdbuild, map, par, etc. In both cases, the 32
bit version of software was used. Peak memory usage (during map) was
just under 3GBytes. Map was run with the -speed option.

Regards,
Allan

I should have some results in a few days. I'm waiting on the delivery of
a Thermalright Ultra 120 heatsink, I should have it tomorrow. I'm
building a system with a 920, 12G of DDR3 1600 and an Asus motherboard.

 

[mng]

On Aug 6, 7:21 am, Allan Herriman <allanherri...@hotmail.com> wrote:

Using ISE8.2 SP3 (yes, 8.2) on an old test design that almost filled a
medium sized fpga, we recorded a run time of 6 hours and 12 minutes for
the older AMD machine, and 3 hours and 3 minutes for the new i7 machine.  
That's 2.03 times as fast.

Thanks for the data. Since it was ISE8.2, I assume that the software
couldn't take advantage of the additional cores? It should be
interesting to see how much of a difference the multi-threaded place &
route in ISE11 makes.

 

[Allan Herriman]

On Thu, 06 Aug 2009 14:21:34 +0000, Allan Herriman wrote:

On Tue, 28 Jul 2009 15:22:25 +0000, Allan Herriman wrote:

On Sun, 26 Jul 2009 10:28:03 -0700, Muzaffer Kal wrote:

On 26 Jul 2009 16:23:16 GMT, General Schvantzkoph
schvantzkoph@yahoo.com> wrote:

Has anyone benchmarked Core7 vs Core2 on NCverilog, Questa, Xilinx and
Altera FPGA tools?

I'd also be very interested in Core7 vs Phenom II performance too
(45nm AMD ie Phenom II 955 etc.)


We just got a new i7 machine for FPGA builds. It tested at just over
twice as fast as our high-end AMD box that was 2-3 years old.

I will publish the results in this ng within a week or two, assuming I
can ever get the licensing for ISE 11.2 running on it. (Thanks Xilinx,
flexlm was a really good move.)


It's been a week and we still can't get the Xilinx licensing working on
the new machine, so I can't post any ISE11.2 results. I assume we will
be able to get the licensing running soon, because I have told the local
Xilinx reps that I won't be designing their parts into new products if
we can't run the software. My last big design used an Altera FPGA, so
they know I'm not joking.

Here are the two machines:

Old machine:
AMD Phenom 9750 CPU 2.40GHz
MSI K9A2-CD-F Motherboard (AMD 790X Chipset) 8GB Corsair
TWIN2X2048-8500C5DF Xtreme CL5 DDR2 RAM (1066MHz) Windows XP
Professional x64 Edition Version 2003 Service Pack 2

New machine:
Intel Core i7 Extreme Edition 975 CPU 3.33GHz Asus Rampage-II-Extreme
Motherboard (Intel X58 Chipset) 12GB OCZ Platinum Low-Voltage Triple
Channel CL7 DDR3 RAM (1600MHz), Windows Server 2003 R2 Standard x64
Edition Service Pack 2.


Using ISE8.2 SP3 (yes, 8.2) on an old test design that almost filled a
medium sized fpga, we recorded a run time of 6 hours and 12 minutes for
the older AMD machine, and 3 hours and 3 minutes for the new i7 machine.
That's 2.03 times as fast.

The runs contained XST, ngdbuild, map, par, etc. In both cases, the 32
bit version of software was used. Peak memory usage (during map) was
just under 3GBytes. Map was run with the -speed option.

Regards,
Allan

I should point out that hyperthreading was turned ON on the i7 machine.
The results might be a little quicker with hyperthreading turned off.
I'm not worried about the loss of parallelism here; the thing has four
cores, each capable of hyperthreading, and most of the cores will be idle
most of the time.

The FPGA build machines here are dedicated to doing just that and are
headless. We use different machines for desktop work and simulations,
etc.

Regards,
Allan

 

[General Schvantzkoph]

On Sun, 26 Jul 2009 16:23:16 +0000, General Schvantzkoph wrote:

Has anyone benchmarked Core7 vs Core2 on NCverilog, Questa, Xilinx and
Altera FPGA tools?

I have an iCore7 system up and running. It's a 920 overclocked to 3.6GHz
using a Thermalright Ultra 120 Extreme. 3.6GHz seems to be the limit for
stable operation. I also have a Core2 P8400 overclocked to 4GHz, it's
been running at that speed for a year without problems.

The iCore7 seems to be better for Xilinx tools, worse for NCSim. Here are
the times (in seconds) for a Xilinx build (11.1 tools, Virtex6) and an
NCVerilog regression. Both systems are running on 64 bit Fedora 11 with
8G of RAM.

iCore7 Core2 iCore7/Core2 Normalized
GHz 3.6 4
Xilinx 2040 2259 110.74% 123.04%
NCverilog 1660 1358 81.81% 90.90%

NC is incredibly cache sensitive, my guess is that the iCore7's three
level cache doesn't work very well for NC.

 

[Chris]

On Sep 25, 9:19 am, Poojan Wagh <poojanw...@gmail.com> wrote:

I'd like to set up automated unit test scripts. (I'm using Riviera Pro
2009.06.) Does anyone know a good way of doing this?

For example, I've written assertion-based unit tests for most of my
modules. I'd like something to run each test and summarize the
results. I know I could probably do so with a csh/bash script.
However, I was looking for something more canned if it exists.

I don't know about Riviera but if you use MyHDL you get all the
benefits of the Python Universe. Unit test and batteries included.

 

[Ed McGettigan]

On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote:

On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

I would strongly encourage you to change the RESET function from
asynchronous to synchronous.

On what basis do you make this recommendation, and what does this have
to do with latches?

Andy

Synchronous versus asynchronous resets have been discussed at length
in other threads.

Asynchronous resets have their place in a designer's toolbox, however
they should be used sparingly. Some reasons to use these are for
handshakes crossing clock domains, anticipated loss of clock and
asynchronous inputs to the synchronous domain.

In a synchronous domain, such as the original state machine example,
the asynchronous functionality offers no additional benefit in FPGAs
as the area cost is identical for both.

Asynchronously asserting and de-asserting a reset across multiple
registers may/will result in the registers being released before and
after a clock edge due to large net delay and skew on the reset net.
This will result in different parts of a design coming out of reset
across clock boundaries and being out of sync with each other.

Synchronous resets simplify timing analysis and timing closure without
having to worry about the consequences of the asynchronous functions
and how to correctly constrain them.

I often see problems with FPGA designs that are built with
asynchronous resets, but I have yet to see a problem with a FPGA
design that was traced to a synchronous reset.

In an FPGA there is no downside to a synchronous reset, but there are
many pitfalls with an asynchronous reset.

None of this has anything to do with a latch, which you also want to
avoid using in an FPGA.

Ed McGettigan
--
Xilinx Inc.

 

[Andy]

On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote:

On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

I would strongly encourage you to change the RESET function from
asynchronous to synchronous.

On what basis do you make this recommendation, and what does this have
to do with latches?

Andy

Synchronous versus asynchronous resets have been discussed at length
in other threads.

Asynchronous resets have their place in a designer's toolbox, however
they should be used sparingly.  Some reasons to use these are for
handshakes crossing clock domains, anticipated loss of clock and
asynchronous inputs to the synchronous domain.

In a synchronous domain, such as the original state machine example,
the asynchronous functionality offers no additional benefit in FPGAs
as the area cost is identical for both.

Asynchronously asserting and de-asserting a reset across multiple
registers may/will result in the registers being released before and
after a clock edge due to large net delay and skew on the reset net.
This will result in different parts of a design coming out of reset
across clock boundaries and being out of sync with each other.

Synchronous resets simplify timing analysis and timing closure without
having to worry about the consequences of the asynchronous functions
and how to correctly constrain them.

I often see problems with FPGA designs that are built with
asynchronous resets, but I have yet to see a problem with a FPGA
design that was traced to a synchronous reset.

In an FPGA there is no downside to a synchronous reset, but there are
many pitfalls with an asynchronous reset.

None of this has anything to do with a latch, which you also want to
avoid using in an FPGA.

Ed McGettigan
--
Xilinx Inc.

Given that most sources of reset signals are not already synchronized
to the clock domain(s) that need resetting, both asynchronous and
syncrhonous resets require at least the deasserting edge to be
synchronized. Proper syncrhonization for each case takes the same
amount of design effort and resources.

I will agree that getting the constraints set to make sure that the
synchronous deassertion path meets timing in an asynchronously reset
system can be non-obvious, but that is a tools issue, not a design
issue (in other words, fix the tools!)

Given that an asynchronous reset reliably resets the circuit,
regardless of the presence or stability of the clock signal, when an
asynchronous reset is correctly designed, it is a more reliable reset
than a synchronous one.

Andy

 

[Ed McGettigan]

On Mar 10, 4:25 pm, Andy <jonesa...@comcast.net> wrote:

On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:





On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote:

On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

I would strongly encourage you to change the RESET function from
asynchronous to synchronous.

On what basis do you make this recommendation, and what does this have
to do with latches?

Andy

Synchronous versus asynchronous resets have been discussed at length
in other threads.

Asynchronous resets have their place in a designer's toolbox, however
they should be used sparingly.  Some reasons to use these are for
handshakes crossing clock domains, anticipated loss of clock and
asynchronous inputs to the synchronous domain.

In a synchronous domain, such as the original state machine example,
the asynchronous functionality offers no additional benefit in FPGAs
as the area cost is identical for both.

Asynchronously asserting and de-asserting a reset across multiple
registers may/will result in the registers being released before and
after a clock edge due to large net delay and skew on the reset net.
This will result in different parts of a design coming out of reset
across clock boundaries and being out of sync with each other.

Synchronous resets simplify timing analysis and timing closure without
having to worry about the consequences of the asynchronous functions
and how to correctly constrain them.

I often see problems with FPGA designs that are built with
asynchronous resets, but I have yet to see a problem with a FPGA
design that was traced to a synchronous reset.

In an FPGA there is no downside to a synchronous reset, but there are
many pitfalls with an asynchronous reset.

None of this has anything to do with a latch, which you also want to
avoid using in an FPGA.

Ed McGettigan
--
Xilinx Inc.

Given that most sources of reset signals are not already synchronized
to the clock domain(s) that need resetting, both asynchronous and
syncrhonous resets require at least the deasserting edge to be
synchronized. Proper syncrhonization for each case takes the same
amount of design effort and resources.

I will agree that getting the constraints set to make sure that the
synchronous deassertion path meets timing in an asynchronously reset
system can be non-obvious, but that is a tools issue, not a design
issue (in other words, fix the tools!)

Given that an asynchronous reset reliably resets the circuit,
regardless of the presence or stability of the clock signal, when an
asynchronous reset is correctly designed, it is a more reliable reset
than a synchronous one.

Andy- Hide quoted text -

- Show quoted text -

I wouldn't take it as a given that most resets are not already
synchronized to the clock domains. Resets are routinely used based on
termination count, end of packet, return to state0 from other states
or invalid states, etc.... All of these cases would be within the
same clock domain.

Placing the onus of creating a reliable design on software tools to
correctly determine the designer's intent for timing paths that are
"non-obvious" is not a working solution IMHO.

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

Ed McGettigan
--
Xilinx Inc.

 

[-jg]

On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

For Logic 'buried deep', that would be correct, but
for pin-drive logic, having a defined state BEFORE the clock, can be
quite mission-critical.

-jg

 

[Ed McGettigan]

On Mar 10, 5:10 pm, -jg <jim.granvi...@gmail.com> wrote:

On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

 For Logic 'buried deep', that would be correct, but
for pin-drive logic, having a defined state BEFORE the clock, can be
quite mission-critical.

 -jg

I absolutely agree that asynchronous resets have a very valid use in
certain cases. My position is that should be avoided in the general
case.

FPGAs with the asynchronous global set/reset can also get you into
that known state before any clocks are applied.

Ed McGettigan
--
Xilinx Inc.

 

[Weng Tianxiang]

On Mar 10, 5:42 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Mar 10, 5:10 pm, -jg <jim.granvi...@gmail.com> wrote:

On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

 For Logic 'buried deep', that would be correct, but
for pin-drive logic, having a defined state BEFORE the clock, can be
quite mission-critical.

 -jg

I absolutely agree that asynchronous resets have a very valid use in
certain cases.  My position is that should be avoided in the general
case.

FPGAs with the asynchronous global set/reset can also get you into
that known state before any clocks are applied.

Ed McGettigan
--
Xilinx Inc.

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by
a clock enable on a register. "

I am interested in above your comment. Can you list an example to show
"the latch cannot be replaced by
a clock enable on a register"

My opinion is that you never will find an example to support your
claim.

1. Whether generating a latch for a intermediate data or not doesn't
change a state machine's behavior. Do you agree?

2. In a synchronous system, signal's data is valid and used near the
clock triggering edge: between set-up time and hold time. Generating a
latch for intermediate data for a state machine would make system
slower, not faster in any situation.

3. Timing for other signals may be affected, of course.

Weng








Andy

 

[Andy]

On Mar 10, 7:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

I wouldn't take it as a given that most resets are not already
synchronized to the clock domains.  Resets are routinely used based on
termination count, end of packet, return to state0 from other states
or invalid states, etc....  All of these cases would be within the
same clock domain.

OK, now I see where we're missing each other: in the definition of
what constitutes a reset function. When I say reset, I mean "device
initialization", either upon power up, power failure, BIT failure,
system watchdog event, etc. that resets darn near the whole device.
When you say "reset" you mean anytime the logic loads a zero or other
static value into a counter, etc.

Our best practice policies forbid combining local, functional
"restarts" like you mentioned, with the reset (initialization)
circuit, or from using asynchronous (causal) reset/preset controls for
them. If a register is not reset for initialization, it is acceptable
to use a synchronous reset control on a register for functional
restarts, etc. There are a few cases where asynchronous controls are
acceptable in sync boundaries, etc. but they are subject to specific
review and approval. These "restart" functions are, as you say, often
triggered by synchronous signals anyway, and are part of the
functional nature of the design, not part of the initialization.

But for device initialization, our best practices recommend the use of
asynchronous resets where possible (subject to device support).

Placing the onus of creating a reliable design on software tools to
correctly determine the designer's intent for timing paths that are
"non-obvious" is not a working solution IMHO.

Why is it not obvious that an output from a same clocked register,
driving an asynchronous reset input to another same-clocked register,
should be checked for the timing relative to that clock? Every
asynchronously reset register still has a setup and hold requirement
for the deasserting edge of that reset input, so check it the same way
you check synchronous inputs (i.e. depending upon the clock domain of
the driven input). You don't even have to check any asyncrhonous paths
through the registers to do this.

Thanks,

Andy

 

[Andy]

On Mar 10, 8:44 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by
a clock enable on a register. "

I am interested in above your comment. Can you list an example to show
"the latch cannot be replaced by
a clock enable on a register"

Example:

A <= B when ENABLE; -- implies a latch for A
C <= A when rising_edge(CLK); -- a register using A
E <= A or D; -- another combinatorial function using A

If not for E, the latch could be replaced by a clock enable on the C
register. I suppose C could still use a clock enable and the B input
directly, but it does not wholly "replace" the latch, because the
latch is still needed to derive E.

Andy

 

[Weng Tianxiang]

On Mar 11, 9:29 am, Andy <jonesa...@comcast.net> wrote:

On Mar 10, 8:44 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by
a clock enable on a register. "

I am interested in above your comment. Can you list an example to show
"the latch cannot be replaced by
a clock enable on a register"

Example:

A <= B when ENABLE; -- implies a latch for A
C <= A when rising_edge(CLK); -- a register using A
E <= A or D; -- another combinatorial function using A

If not for E, the latch could be replaced by a clock enable on the C
register. I suppose C could still use a clock enable and the B input
directly, but it does not wholly "replace" the latch, because the
latch is still needed to derive E.

Andy

Andy,
We don't argue about the latch replacement as you show. What we argue
about is when a fast next state signal StateA_NS is replaced by a
slower latched version.
It occurs if a condition in an if statement misses a signal assignment
statement as we have been discussing about.

Weng

 

[Andy]

On Mar 11, 1:38 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

On Mar 11, 9:29 am, Andy <jonesa...@comcast.net> wrote:





On Mar 10, 8:44 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by
a clock enable on a register. "

I am interested in above your comment. Can you list an example to show
"the latch cannot be replaced by
a clock enable on a register"

Example:

A <= B when ENABLE; -- implies a latch for A
C <= A when rising_edge(CLK); -- a register using A
E <= A or D; -- another combinatorial function using A

If not for E, the latch could be replaced by a clock enable on the C
register. I suppose C could still use a clock enable and the B input
directly, but it does not wholly "replace" the latch, because the
latch is still needed to derive E.

Andy

Andy,
We don't argue about the latch replacement as you show. What we argue
about is when a fast next state signal StateA_NS is replaced by a
slower latched version.
It occurs if a condition in an if statement misses a signal assignment
statement as we have been discussing about.

Weng- Hide quoted text -

- Show quoted text -

I'm not sure why you are concerned about this. Everyone seems to agree
that inferring latches is not a good idea. The fact that it slows
performance (at least in FPGA's, see below) is just one more reason to
avoid them.

It just so happens that in FPGAs, the clock enable mux is always there
on the front of the flip-flop, so there is no timing penalty whether
you actually use it or not, and adding a latch in front of it is
always slower.

In other technologies, you have a choice of having a clock enabled or
regular flip-flop, with the latter being faster. Now the question is,
in such a technology, is the latch plus regular flop faster than the
clock enabled flop?

Andy

 

[Weng Tianxiang]

On Mar 11, 12:08 pm, Andy <jonesa...@comcast.net> wrote:

On Mar 11, 1:38 pm, Weng Tianxiang <wtx...@gmail.com> wrote:





On Mar 11, 9:29 am, Andy <jonesa...@comcast.net> wrote:

On Mar 10, 8:44 pm, Weng Tianxiang <wtx...@gmail.com> wrote:

Andy,
"Some synthesis tools may be getting smart enough to optimize an
inferred latch from a combinatorial process into a clock enable on
the
corresponding register implied by the clocked process. But if there
are any other combinatorial processes that use that latched output of
the first combinatorial process, then the latch cannot be replaced by
a clock enable on a register. "

I am interested in above your comment. Can you list an example to show
"the latch cannot be replaced by
a clock enable on a register"

Example:

A <= B when ENABLE; -- implies a latch for A
C <= A when rising_edge(CLK); -- a register using A
E <= A or D; -- another combinatorial function using A

If not for E, the latch could be replaced by a clock enable on the C
register. I suppose C could still use a clock enable and the B input
directly, but it does not wholly "replace" the latch, because the
latch is still needed to derive E.

Andy

Andy,
We don't argue about the latch replacement as you show. What we argue
about is when a fast next state signal StateA_NS is replaced by a
slower latched version.
It occurs if a condition in an if statement misses a signal assignment
statement as we have been discussing about.

Weng- Hide quoted text -

- Show quoted text -

I'm not sure why you are concerned about this. Everyone seems to agree
that inferring latches is not a good idea. The fact that it slows
performance (at least in FPGA's, see below) is just one more reason to
avoid them.

It just so happens that in FPGAs, the clock enable mux is always there
on the front of the flip-flop, so there is no timing penalty whether
you actually use it or not, and adding a latch in front of it is
always slower.

In other technologies, you have a choice of having a clock enabled or
regular flip-flop, with the latter being faster. Now the question is,
in such a technology, is the latch plus regular flop faster than the
clock enabled flop?

Andy

Andy,
Thank you for your comments.

Weng

 

[rickman]

On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Mar 10, 4:25 pm, Andy <jonesa...@comcast.net> wrote:



On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote:

On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

I would strongly encourage you to change the RESET function from
asynchronous to synchronous.

On what basis do you make this recommendation, and what does this have
to do with latches?

Andy

Synchronous versus asynchronous resets have been discussed at length
in other threads.

Asynchronous resets have their place in a designer's toolbox, however
they should be used sparingly.  Some reasons to use these are for
handshakes crossing clock domains, anticipated loss of clock and
asynchronous inputs to the synchronous domain.

In a synchronous domain, such as the original state machine example,
the asynchronous functionality offers no additional benefit in FPGAs
as the area cost is identical for both.

Asynchronously asserting and de-asserting a reset across multiple
registers may/will result in the registers being released before and
after a clock edge due to large net delay and skew on the reset net.
This will result in different parts of a design coming out of reset
across clock boundaries and being out of sync with each other.

Synchronous resets simplify timing analysis and timing closure without
having to worry about the consequences of the asynchronous functions
and how to correctly constrain them.

I often see problems with FPGA designs that are built with
asynchronous resets, but I have yet to see a problem with a FPGA
design that was traced to a synchronous reset.

In an FPGA there is no downside to a synchronous reset, but there are
many pitfalls with an asynchronous reset.

None of this has anything to do with a latch, which you also want to
avoid using in an FPGA.

Ed McGettigan
--
Xilinx Inc.

Given that most sources of reset signals are not already synchronized
to the clock domain(s) that need resetting, both asynchronous and
syncrhonous resets require at least the deasserting edge to be
synchronized. Proper syncrhonization for each case takes the same
amount of design effort and resources.

I will agree that getting the constraints set to make sure that the
synchronous deassertion path meets timing in an asynchronously reset
system can be non-obvious, but that is a tools issue, not a design
issue (in other words, fix the tools!)

Given that an asynchronous reset reliably resets the circuit,
regardless of the presence or stability of the clock signal, when an
asynchronous reset is correctly designed, it is a more reliable reset
than a synchronous one.

Andy- Hide quoted text -

- Show quoted text -

I wouldn't take it as a given that most resets are not already
synchronized to the clock domains.  Resets are routinely used based on
termination count, end of packet, return to state0 from other states
or invalid states, etc....  All of these cases would be within the
same clock domain.

Placing the onus of creating a reliable design on software tools to
correctly determine the designer's intent for timing paths that are
"non-obvious" is not a working solution IMHO.

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

Ed McGettigan
--
Xilinx Inc.

I don't follow that at all. I use async resets all the time, but I
use them appropriately. I don't expect them to release all FFs at the
same time and design that way. That's all it takes. No magic, mo
complex design techniques. I just don't assume a counter will have
all bits start at the same clock cycle, give or take one cycle. But a
binary counter will only increment the lsb if started at count 0. So
it will start correctly if the rest of the bits are released in the
next clock cycle or the one before. My state machine designs include
a start state that is just to allow the state machine to release from
reset. The list goes on. But nothing on the list is hard to
understand or to implement. More importantly, an async reset and the
small amount of logic required to release FFs from the async reset is
less logic than adding a sync reset to every FF in the design. AND
it will operate irrespective of the state of the clock!

Rick

 

[rickman]

On Mar 10, 8:42 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Mar 10, 5:10 pm, -jg <jim.granvi...@gmail.com> wrote:

On Mar 11, 2:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

 For Logic 'buried deep', that would be correct, but
for pin-drive logic, having a defined state BEFORE the clock, can be
quite mission-critical.

 -jg

I absolutely agree that asynchronous resets have a very valid use in
certain cases.  My position is that should be avoided in the general
case.

FPGAs with the asynchronous global set/reset can also get you into
that known state before any clocks are applied.

Ed McGettigan

My understanding is the global set/reset is what we are talking about
when we say "async reset". That is what it is mapped to in all of my
designs.

Rick

 

[Magne Munkejord]

rickman wrote:

On Mar 10, 8:01 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On Mar 10, 4:25 pm, Andy <jonesa...@comcast.net> wrote:



On Mar 10, 1:24 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
On Mar 10, 10:06 am, Andy <jonesa...@comcast.net> wrote:
On Mar 9, 12:15 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
I would strongly encourage you to change the RESET function from
asynchronous to synchronous.
On what basis do you make this recommendation, and what does this have
to do with latches?
Andy
Synchronous versus asynchronous resets have been discussed at length
in other threads.
Asynchronous resets have their place in a designer's toolbox, however
they should be used sparingly. Some reasons to use these are for
handshakes crossing clock domains, anticipated loss of clock and
asynchronous inputs to the synchronous domain.
In a synchronous domain, such as the original state machine example,
the asynchronous functionality offers no additional benefit in FPGAs
as the area cost is identical for both.
Asynchronously asserting and de-asserting a reset across multiple
registers may/will result in the registers being released before and
after a clock edge due to large net delay and skew on the reset net.
This will result in different parts of a design coming out of reset
across clock boundaries and being out of sync with each other.
Synchronous resets simplify timing analysis and timing closure without
having to worry about the consequences of the asynchronous functions
and how to correctly constrain them.
I often see problems with FPGA designs that are built with
asynchronous resets, but I have yet to see a problem with a FPGA
design that was traced to a synchronous reset.
In an FPGA there is no downside to a synchronous reset, but there are
many pitfalls with an asynchronous reset.
None of this has anything to do with a latch, which you also want to
avoid using in an FPGA.
Ed McGettigan
--
Xilinx Inc.
Given that most sources of reset signals are not already synchronized
to the clock domain(s) that need resetting, both asynchronous and
syncrhonous resets require at least the deasserting edge to be
synchronized. Proper syncrhonization for each case takes the same
amount of design effort and resources.
I will agree that getting the constraints set to make sure that the
synchronous deassertion path meets timing in an asynchronously reset
system can be non-obvious, but that is a tools issue, not a design
issue (in other words, fix the tools!)
Given that an asynchronous reset reliably resets the circuit,
regardless of the presence or stability of the clock signal, when an
asynchronous reset is correctly designed, it is a more reliable reset
than a synchronous one.
Andy- Hide quoted text -
- Show quoted text -
I wouldn't take it as a given that most resets are not already
synchronized to the clock domains. Resets are routinely used based on
termination count, end of packet, return to state0 from other states
or invalid states, etc.... All of these cases would be within the
same clock domain.

Placing the onus of creating a reliable design on software tools to
correctly determine the designer's intent for timing paths that are
"non-obvious" is not a working solution IMHO.

The cons of an asynchronous reset significantly outweigh the single
pro that the reset will occur in the absence of clock.

Ed McGettigan
--
Xilinx Inc.

I don't follow that at all. I use async resets all the time, but I
use them appropriately. I don't expect them to release all FFs at the
same time and design that way. That's all it takes. No magic, mo
complex design techniques. I just don't assume a counter will have
all bits start at the same clock cycle, give or take one cycle. But a
binary counter will only increment the lsb if started at count 0. So
it will start correctly if the rest of the bits are released in the
next clock cycle or the one before. My state machine designs include
a start state that is just to allow the state machine to release from
reset. The list goes on. But nothing on the list is hard to
understand or to implement. More importantly, an async reset and the
small amount of logic required to release FFs from the async reset is
less logic than adding a sync reset to every FF in the design. AND
it will operate irrespective of the state of the clock!

Rick
AFAIK, the reset and set ports in flip flops in Xilinx FPGAs can be

configured to be either asynchronous or synchronous. So there is no
extra logic required to implement synchronous resets.
In fact, if you don't specify a reset for a register, the reset and set
ports can be used as logic inputs, so you can put more logic in a slice.

If your design has outputs that are critical you can use async reset on
the output registers or use logic to set the output asynchronously.

I use a reset circuit that holds the design in reset until the DCM/PLL's
locked output is asserted, and then some cycles. Then I know I have a
stable clock before the design starts up.

Magne