need a cheap student edition FPGA

[rickman]

On Mar 15, 8:14 am, Magne Munkejord <magnem...@yahoo.no> wrote:

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.

You would think that. I just had to change some code to eliminate a
sync reset on a register to get rid of one level of LUTs in a Lattice
design which has a similar if not same FF structure with the dedicated
LSR input (Local Set/Reset). Synplify seems to not know how to use
that. Maybe this would get changed by the mapper, but I don't think
it does that. I was looking at it in the synthesis tool. Have you
tried an example? Does Synplify do a better job with the Xilinx parts
than they do with Lattice parts? I'm not convinced they do a good job
with the arithmetic units. It is more than once I've seen an adder
chain duplicated to get the carry out of the top!

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.

This issue is very complex in the real world. Once you find a
solution you like, most people stick with it regardless. I haven't
found a problem with the async reset and it always starts the chip in
the same state no matter what! I just pay a little attention to how
my circuits come out of an async reset which I don't find difficult at
all. I haven't tried the PLL yet. That may be in a later design, so
I may have to change my methods.

Rick

 

[Magne Munkejord]

rickman wrote:

You would think that. I just had to change some code to eliminate a
sync reset on a register to get rid of one level of LUTs in a Lattice
design which has a similar if not same FF structure with the dedicated
LSR input (Local Set/Reset). Synplify seems to not know how to use
that. Maybe this would get changed by the mapper, but I don't think
it does that. I was looking at it in the synthesis tool. Have you
tried an example? Does Synplify do a better job with the Xilinx parts
than they do with Lattice parts? I'm not convinced they do a good job
with the arithmetic units. It is more than once I've seen an adder
chain duplicated to get the carry out of the top!

Hi Rick,

I tried 5-input registered OR, like this:

p_sync_or : process (clk) is
begin
if rising_edge(clk) then
q <= a or b or c or d or e;
end if;
end process p_sync_or;

In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
port of the register, and so does not require two LUTs to implement the
gate.

When it comes to Synplify I only have the actel edition ( only actel
parts supported(?)) and I have hardly ever used it.

I think actel parts only support async resets for their registers, in
which case it is true as you say, that designing synchronous resets will
generate extra logic in front of the registers. Maybe this is true for
Lattice as well. In that case I would prefer using an async reset to
avoid the extra logic and performance penalty.

If the reset signal is synchronously deasserted, it can be constrained
so that one is certain it will reach each register at a proper time.

Magne

 

[Weng Tianxiang]

On Mar 16, 2:04 am, Magne Munkejord <magnem...@yahoo.no> wrote:

rickman wrote:
You would think that.  I just had to change some code to eliminate a
sync reset on a register to get rid of one level of LUTs in a Lattice
design which has a similar if not same FF structure with the dedicated
LSR input (Local Set/Reset).  Synplify seems to not know how to use
that.  Maybe this would get changed by the mapper, but I don't think
it does that.  I was looking at it in the synthesis tool.  Have you
tried an example?  Does Synplify do a better job with the Xilinx parts
than they do with Lattice parts?  I'm not convinced they do a good job
with the arithmetic units.  It is more than once I've seen an adder
chain duplicated to get the carry out of the top!

Hi Rick,

I tried 5-input registered OR, like this:

     p_sync_or : process (clk) is
     begin
         if rising_edge(clk) then
             q <= a or b or c or d or e;
         end if;
     end process p_sync_or;

In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
port of the register, and so does not require two LUTs to implement the
gate.

When it comes to Synplify I only have the actel edition ( only actel
parts supported(?)) and I have hardly ever used it.

I think actel parts only support async resets for their registers, in
which case it is true as you say, that designing synchronous resets will
generate extra logic in front of the registers. Maybe this is true for
Lattice as well. In that case I would prefer using an async reset to
avoid the extra logic and performance penalty.

If the reset signal is synchronously deasserted, it can be constrained
so that one is certain it will reach each register at a proper time.

Magne

Magne,
Your method is wrong !

You cannot connect 'e' to the set port of the register. It may
compromise a new data which uses 'q'.

Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
and changes a data 'New" which uses 'q' during setup or hold time
around the next clock triggering edge.Next 'New' signal data may be
invalid.

p_sync_or : process (clk) is
begin
if rising_edge(clk) then
q <= a or b or c or d or e;
end if;
end process p_sync_or;

A : process(clk)
begin
if rising_edge(clk) then
New <= a and q;
end if;
end process A;

Weng

 

[rickman]

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

On Mar 16, 2:04 am, Magne Munkejord <magnem...@yahoo.no> wrote:







rickman wrote:
You would think that.  I just had to change some code to eliminate a
sync reset on a register to get rid of one level of LUTs in a Lattice
design which has a similar if not same FF structure with the dedicated
LSR input (Local Set/Reset).  Synplify seems to not know how to use
that.  Maybe this would get changed by the mapper, but I don't think
it does that.  I was looking at it in the synthesis tool.  Have you
tried an example?  Does Synplify do a better job with the Xilinx parts
than they do with Lattice parts?  I'm not convinced they do a good job
with the arithmetic units.  It is more than once I've seen an adder
chain duplicated to get the carry out of the top!

Hi Rick,

I tried 5-input registered OR, like this:

     p_sync_or : process (clk) is
     begin
         if rising_edge(clk) then
             q <= a or b or c or d or e;
         end if;
     end process p_sync_or;

In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
port of the register, and so does not require two LUTs to implement the
gate.

When it comes to Synplify I only have the actel edition ( only actel
parts supported(?)) and I have hardly ever used it.

I think actel parts only support async resets for their registers, in
which case it is true as you say, that designing synchronous resets will
generate extra logic in front of the registers. Maybe this is true for
Lattice as well. In that case I would prefer using an async reset to
avoid the extra logic and performance penalty.

If the reset signal is synchronously deasserted, it can be constrained
so that one is certain it will reach each register at a proper time.

Magne

Magne,
Your method is wrong !

You cannot connect 'e' to the set port of the register. It may
compromise a new data which uses 'q'.

Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
and changes a data 'New" which uses 'q' during setup or hold time
around the next clock triggering edge.Next 'New' signal data may be
invalid.

p_sync_or : process (clk) is
     begin
         if rising_edge(clk) then
             q <= a or b or c or d or e;
         end if;
     end process p_sync_or;

A : process(clk)
     begin
         if rising_edge(clk) then
             New <= a and q;
         end if;
     end process A;

Weng

I'm not clear on what your concern is. Perhaps you are thinging Magne
is talking about e being connected to an async set? He is describing
a FF with an async set which will do exactly the same thing as an OR
of signal e with the rest of the inputs.

Rick

 

[Magne Munkejord]

rickman wrote:

On Mar 16, 8:24 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Mar 16, 2:04 am, Magne Munkejord <magnem...@yahoo.no> wrote:







rickman wrote:
You would think that. I just had to change some code to eliminate a
sync reset on a register to get rid of one level of LUTs in a Lattice
design which has a similar if not same FF structure with the dedicated
LSR input (Local Set/Reset). Synplify seems to not know how to use
that. Maybe this would get changed by the mapper, but I don't think
it does that. I was looking at it in the synthesis tool. Have you
tried an example? Does Synplify do a better job with the Xilinx parts
than they do with Lattice parts? I'm not convinced they do a good job
with the arithmetic units. It is more than once I've seen an adder
chain duplicated to get the carry out of the top!
Hi Rick,
I tried 5-input registered OR, like this:
p_sync_or : process (clk) is
begin
if rising_edge(clk) then
q <= a or b or c or d or e;
end if;
end process p_sync_or;
In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
port of the register, and so does not require two LUTs to implement the
gate.
When it comes to Synplify I only have the actel edition ( only actel
parts supported(?)) and I have hardly ever used it.
I think actel parts only support async resets for their registers, in
which case it is true as you say, that designing synchronous resets will
generate extra logic in front of the registers. Maybe this is true for
Lattice as well. In that case I would prefer using an async reset to
avoid the extra logic and performance penalty.
If the reset signal is synchronously deasserted, it can be constrained
so that one is certain it will reach each register at a proper time.
Magne
Magne,
Your method is wrong !

You cannot connect 'e' to the set port of the register. It may
compromise a new data which uses 'q'.
It wasn't me, XST did it!

Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
and changes a data 'New" which uses 'q' during setup or hold time
around the next clock triggering edge.Next 'New' signal data may be
invalid.

p_sync_or : process (clk) is
begin
if rising_edge(clk) then
q <= a or b or c or d or e;
end if;
end process p_sync_or;

A : process(clk)
begin
if rising_edge(clk) then
New <= a and q;
end if;
end process A;

Weng
Since the 'set' port of the register is synchronous the circuit will

behave as your code above describes it. q will not change state before
rising edge of clk even if e is asserted earlier. I would think the
timing tools knows the required setup time for the synchronous set/reset
ports, and cover their paths as any other synchronous elements.

I'm not clear on what your concern is. Perhaps you are thinging Magne
is talking about e being connected to an async set? He is describing
a FF with an async set which will do exactly the same thing as an OR
of signal e with the rest of the inputs.

Rick
The second instance of 'async' I would correct to 'sync', but I guess

that was a typo.

Magne

 

[fpgabuilder]

On Mar 10, 12: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.
I know Altera's Quartus Timing Analyzer has recovery/removal analysis.

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 have not used Xilinx devices with Synchronous resets. I am curious

is it ever possible that the clock may stop before the reset event and
then subsequently the clock appears after the reset event passes
thereby not initializing the logic?

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]

Andy

"ever possible"? Yes. That's one reason why I prefer async resets for
device initialization (but not for simply setting a counter back to
zero during its normal course of operation, etc.)

Andy

 

[Weng Tianxiang]

On Mar 18, 8:00 am, Andy <jonesa...@comcast.net> wrote:

Andy

"ever possible"? Yes.  That's one reason why I prefer async resets for
device initialization (but not for simply setting a counter back to
zero during its normal course of operation, etc.)

Andy

fpgabuilder,

From Sun code documents of OpenSparc CPU T2, there are 6 types of
reset signals, a situation much more complexer than we think.

Weng

 

[rickman]

On Mar 17, 6:24 am, Magne Munkejord <magnem...@yahoo.no> wrote:

rickman wrote:
On Mar 16, 8:24 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
On Mar 16, 2:04 am, Magne Munkejord <magnem...@yahoo.no> wrote:

rickman wrote:
You would think that.  I just had to change some code to eliminate a
sync reset on a register to get rid of one level of LUTs in a Lattice
design which has a similar if not same FF structure with the dedicated
LSR input (Local Set/Reset).  Synplify seems to not know how to use
that.  Maybe this would get changed by the mapper, but I don't think
it does that.  I was looking at it in the synthesis tool.  Have you
tried an example?  Does Synplify do a better job with the Xilinx parts
than they do with Lattice parts?  I'm not convinced they do a good job
with the arithmetic units.  It is more than once I've seen an adder
chain duplicated to get the carry out of the top!
Hi Rick,
I tried 5-input registered OR, like this:
     p_sync_or : process (clk) is
     begin
         if rising_edge(clk) then
             q <= a or b or c or d or e;
         end if;
     end process p_sync_or;
In a Virtex4 (4 input LUTs) XST synthesis connects input 'e' to the set
port of the register, and so does not require two LUTs to implement the
gate.
When it comes to Synplify I only have the actel edition ( only actel
parts supported(?)) and I have hardly ever used it.
I think actel parts only support async resets for their registers, in
which case it is true as you say, that designing synchronous resets will
generate extra logic in front of the registers. Maybe this is true for
Lattice as well. In that case I would prefer using an async reset to
avoid the extra logic and performance penalty.
If the reset signal is synchronously deasserted, it can be constrained
so that one is certain it will reach each register at a proper time.
Magne
Magne,
Your method is wrong !

You cannot connect 'e' to the set port of the register. It may
compromise a new data which uses 'q'.

It wasn't me, XST did it!



Imagine the case: if 'e' is so earlier asserted that 'q' is asserted
and changes a data 'New" which uses 'q' during setup or hold time
around the next clock triggering edge.Next 'New' signal data may be
invalid.

p_sync_or : process (clk) is
     begin
         if rising_edge(clk) then
             q <= a or b or c or d or e;
         end if;
     end process p_sync_or;

A : process(clk)
     begin
         if rising_edge(clk) then
             New <= a and q;
         end if;
     end process A;

Weng

Since the 'set' port of the register is synchronous the circuit will
behave as your code above describes it. q will not change state before
rising edge of clk even if e is asserted earlier. I would think the
timing tools knows the required setup time for the synchronous set/reset
ports, and cover their paths as any other synchronous elements.

I'm not clear on what your concern is.  Perhaps you are thinging Magne
is talking about e being connected to an async set?  He is describing
a FF with an async set which will do exactly the same thing as an OR
of signal e with the rest of the inputs.

Rick

The second instance of 'async' I would correct to 'sync', but I guess
that was a typo.

Magne

Yes, it was a typo... in other words, a mistake... Why do they call
it a "typo". It was a mistake regardless of how you categorize it.

Rick

 

[rickman]

On Mar 18, 11:41 am, Weng Tianxiang <wtx...@gmail.com> wrote:

On Mar 18, 8:00 am, Andy <jonesa...@comcast.net> wrote:

Andy

"ever possible"? Yes.  That's one reason why I prefer async resets for
device initialization (but not for simply setting a counter back to
zero during its normal course of operation, etc.)

Andy

fpgabuilder,

From Sun code documents of OpenSparc CPU T2, there are 6 types of
reset signals, a situation much more complexer than we think.

Weng

Ok, go ahead and tease us! Or are you going to share with us what the
six types are?

Rick

 

[fpgabuilder]

On Mar 19, 6:32 am, rickman <gnu...@gmail.com> wrote:

On Mar 18, 11:41 am, Weng Tianxiang <wtx...@gmail.com> wrote:



On Mar 18, 8:00 am, Andy <jonesa...@comcast.net> wrote:

Andy

"ever possible"? Yes.  That's one reason why I prefer async resets for
device initialization (but not for simply setting a counter back to
zero during its normal course of operation, etc.)

Andy

fpgabuilder,

From Sun code documents of OpenSparc CPU T2, there are 6 types of
reset signals, a situation much more complexer than we think.

Weng

Ok, go ahead and tease us!  Or are you going to share with us what the
six types are?

Rick

Yeah! What are those?

 

[Jonathan Bromley]

On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote:

[Weng]

there are 6 types of
reset signals, a situation much more complexer than we think.

Ok, go ahead and tease us! Or are you going to share with us what the
six types are?

1. Reset that is asserted at the right time,
but has the wrong polarity, thus holding the design
in reset throughout your test.
2. Reset with the right polarity that is not asserted
reliably at power-up, because you were too cheap
to spend $0.70 on a power monitor/watchdog chip.
3. Reset that is triggered at random times during
operation because it is laid out on the PCB too
close to a data bus. Capacitive coupling causes
reset to be momentarily asserted when more than
80% of the data lines transition simultaneously.
4. Reset that is asserted correctly, but is released
too close to a clock edge and causes the design
to go into an illegal state because some flops
respond to the clock and others don't.
5. Reset of a counter, used by a designer who thought
it would be a cool way to make the counter go back
to zero when it overflows some programmed limit.
6. Reset that is triggered by the operation of a
system-level watchdog. It causes the CPU to stop
operating roughly a millisecond before emitting
the debug message that would have allowed you
to diagnose the problem.

Just in case you thought I was fooling, I should point
out that I have had to debug and correct each of these
at some point in my career. One or two of them were
someone else's fault
--
Jonathan Bromley

 

[Weng Tianxiang]

On Mar 19, 2:31 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote:

[Weng]

there are 6 types of
reset signals, a situation much more complexer than we think.
Ok, go ahead and tease us!  Or are you going to share with us what the
six types are?

1. Reset that is asserted at the right time,
   but has the wrong polarity, thus holding the design
   in reset throughout your test.
2. Reset with the right polarity that is not asserted
   reliably at power-up, because you were too cheap
   to spend $0.70 on a power monitor/watchdog chip.
3. Reset that is triggered at random times during
   operation because it is laid out on the PCB too
   close to a data bus.  Capacitive coupling causes
   reset to be momentarily asserted when more than
   80% of the data lines transition simultaneously.
4. Reset that is asserted correctly, but is released
   too close to a clock edge and causes the design
   to go into an illegal state because some flops
   respond to the clock and others don't.
5. Reset of a counter, used by a designer who thought
   it would be a cool way to make the counter go back
   to zero when it overflows some programmed limit.
6. Reset that is triggered by the operation of a
   system-level watchdog.  It causes the CPU to stop
   operating roughly a millisecond before emitting
   the debug message that would have allowed you
   to diagnose the problem.

Just in case you thought I was fooling, I should point
out that I have had to debug and correct each of these
at some point in my career.  One or two of them were
someone else's fault
--
Jonathan Bromley

Hi,
Here is where you can find the contents:
http://www.opensparc.net/opensparc-t2/download.html

1. /doc/OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf
2. /doc/OpenSPARCT2_SoC_Micro_Arch_Vol2.pdf

3. There are too many reset descriptions. I just copy the most
important context here.

2.2.2 Reset Sequence for L2 cache
In L2 cache, parity bits in the tag array, valid bits in VUAD array
and the directories
should be initialized before L2 cache is enabled to guarantee
coherency and correct
functionality.
The directory valid bits are cleared with flash reset during POR_. The
reset block
drives the flash reset. When the valid bits are cleared (not valid)
then the entries are
don’t care. Hence, the parity bits are not initialized to good parity.
Clearing valid
bits in the directory informs the L2 cache that there are no valid
lines in L1.
BISI or ASIs are used to initialize the VUAD arrays by clearing all
the valid bits. This
informs L2 cache that there are no valid lines in L2.
BISI or ASIs are used to initialize the tag array with good parity.
This eliminates the
possibility of any error cases from happening.

4.16.6 ASIC Reset
The ASIC blocks in OpenSPARC T2 DMU are treated differently from other
clusters
during the reset sequence and warm or debug resets.
During POR1 the DMU has its clocks stopped until the RST unit tells
TCU to release
them with rst_tcu_asicflush_stop_req; this signal comes earlier than
rst_tcu_flush_stop_req. When the asicflush_stop_req is received, TCU
releases itself
from its own flush reset and turns off the clock stops to the ASICs
and deasserts
tcu_asic_scan_en. The tcu_asic_aclk is not asserted at all during
POR1, preventing a
flush state to the ASICs. During subsequent resets (WMR1, WMR2) the
ASIC clock
stops are allowed to activate in the normal clock stop sequence but
the ASICs are not
4-90 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
May 2008
flushed. During debug resets (DBR) the signal rst_tcu_dbr_gen is
active and TCU
does not activate the clock stops to the ASICs to allow them to
continue running.
During JTAG clock stop operations, these blocks behave as other SOC
blocks. During
POR2 the ASIC clock stops will be held deasserted.

5.3.2 Reset Scheme
The CCU relies on the RST block for explicit reset signals, and does
not operate via
flush reset. Also, it needs to be released from reset before all other
blocks on the
chip. One reset is solely for the PLL, and the other for the remaining
CCU logic,
loosely speaking. The CCU itself needs to generate one or two
staggered resets.
These resets work in a domino like fashion to ultimately provide a
signal to the RST
unit that indicates the CCU is done with initialization, and that the
RST block may
release the rest of the chip from reset. This signal is
ccu_rst_sync_stable. When the
signal goes high, all clocks from the CCU are valid, at the correct
frequency, and all
sync pulses are operating in their proper positions.
Depending on whether clocks may be stable or not, the CCU needs to use
either
asynchronous or synchronous reset. However, all resets within the CCU
are released
synchronously. Emphasis has been placed on determinism and
repeatability, so even
where brute-force synchronization is used, additional signals ensure
determinism.
There is only one CSR register in the CCU that is warm reset
protected. All clock
generating and pll programmation bits are warm reset protected. The
rest are not.
5.3.3 Initialization Sequence
The Power-On-Reset scheme in the CCU is highlighted by the waveforms
in
FIGURE 5-9. For functional operation, the CCU is activated in a very
simple manner.
There are two resets to the CCU, ccu_rst_pll_ and ccu_rst_ that need
to be applied
in a sequence. Testmode, and divider_bypass pins need to be held low.
Chapter 5 Clock Control Unit (CCU) 5-17
An explanation of the various numbered parameters is given in TABLE
5-5.
TABLE 5-5 Key Parameters in Initialization Sequence
Parm # Description Duration
1 Time taken for first rising edge of refclk to appear from release of
rst_ccu_pll_ <1 sys_clk cycle
2 Deassertion of rst_ccu_pll_ to rising edge of stable CMP PLL clock
output LOCK TIME
3 Clock distribution delay of global clock tree from PLL output to
gclk input of
cluster header
~0.5 – ~1.3 CMP
cycle
4 Deassertion of rst_ccu_ to gclk_rst_n (requires use of brute force
synchronizer) 1 to 2 CMP cycles
5 Rising edge of refclk to assertion of aligned_shift pulse. 3 CMP
cycles
6 Shift of aligned_shift pulse to create VCO aligned 4 to 17 CMP
cycles depending
on pll_div2[5:0]
7 Transfer of aligned signal from CMP PLL domain to CMP_GCLK domain.
Tracks parameter
#3
8 From first aligned pulse to aligned_rst_n signal for internal CCU
blocks for
coherent reset release.
1 CMP cycle
9 Deassertion of aligned_rst_n to first rising edge of ccu_io2x_out 2
CMP cycles
10 Deassertion of aligned_rst_n to first rising edge of ccu_io_out 4
CMP cycles
11 Time when aligned == 1 to deassertion of divider for generating DR
clock
within PLL
2-3 CMP cycles
depending on
pll_div4[6:0]
12 Deassertion of dft_a_rst_l to first rising edge of dr_clk 5-6 CMP
cycles
depending on
pll_div4[6:0]
5-18 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
May 2008
FIGURE 5-7 CCU Clock Domains and Function
Chapter 5 Clock Control Unit (CCU) 5-19
FIGURE 5-8 Align Detection Circuitry
FIGURE 5-9 Initialization Sequence for CCU Clocks
5-20 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
May 2008
5.4 Sync Pulses
The main application of generating synchronization pulses in OpenSPARC
T2 is to
allow low latency, deterministic data transfer between ratioed
synchronous clock
domains. The key requirements for this scheme to work are:
A single reference clock source.
PLLs that have similar behavior, in particular a known input-output
phase
relationship.
The clock frequencies need to be rational multiples of each other, or
ratioed
synchronous
Jitter, skew, and other PVT mismatches are taken into account to
ensure setup and
hold requirements are met during domain crossing.
Clock domains that are of primary concern are the CMP and DR domains.
Synchronization between cmp and IO, or IO2X domains is a simpler
problem, but
handled similarly.
5.4.1 Proposed Scheme
The following circuit shows the proposed scheme for clock domain
transfers.
FIGURE 5-10 CMP to DR Synchronization
Chapter 5 Clock Control Unit (CCU) 5-21
FIGURE 5-11 DR to CMP Synchronization
It has been borrowed from past designs and modified. All it does is
allow data to
cross one domain to another during a safe interval, avoiding setup and
hold
problems. The mechanism for operation for fast clock (e.g., cmp) to
slow clock (e.g.,
dr) domain is as follows:
Mux enable to launch flip-flop is generated on cmp_clk.
Next cmp rising edge, data is launched.
Data is captured on dr_clk.
For slow clock to fast clock transfers, the procedure is:
Data is launched on rising edge of dr_clk.
Mux enable to capture flip-flop is generated on cmp_clk.
Next cmp rising edge, data is captured.
In both cases, the rate of communication is limited by the slower
clock frequency, so
the enable is generated once every slow clock cycle. The main
challenge is to
determine the ideal intervals between pulse generation for robust
operation. For a
discussion on determining the positions, refer to Appendix A.1 – Sync
Pulse Design
Procedure.
5-22 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
May 2008
5.4.2 Sync Pulse Distribution
FIGURE 5-12 Logical Representation of Sync Pulse Global Distribution
Sync pulses will be generated in the CCU on the cmp_gclk domain, and
be
distributed (along with other control signals) in five stages of
pipeline in
mini-clusters to each cluster header. In the cluster headers, there
will be one more
stage of latching the data on the gclk domain. From there, each
cluster will flop the
enables on the l2clk domains before local distribution. In effect,
there will be seven
stages of cmp_cycle before sync pulses are output from cluster
headers, and then
flopped one last time within clusters.
Chapter 5 Clock Control Unit (CCU) 5-23
5.4.3 CMP to IO/IO2X Waveforms
Domain crossing between CMP and IO/IO2X domains is a special, and
simpler case
of CMP to DR communication because cmp_clk is an integer multiple of
io_clk and
io2x_clk, and both io_clk and io2x_clk are directly derived from
cmp_clk
FIGURE 5-13 shows the actual usage, i.e., the final sync_en output
(refer to FIGURE 5-9).
FIGURE 5-13 Actual Usage of Sync Pulses at Enable Pin of Transfer
Flops
Note – Since cmp_io2x_sync_en and io2x_cmp_sync_en are shown at the
point of
usage; however, they would both be driven by a single source – cluster
header->io2x_sync_en ->flop output.
5-24 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
May 2008
For clarity, the outputs of cluster headers are also shown. These are,
as expected
from FIGURE 5-9, one l2clk cycle early.
FIGURE 5-14 Sync Enable Positions at the Outputs of Cluster Headers
prior to being latched.
5.4.4 CMP/DR Pulses
CMP to DR pulse positions are determined by the amount of uncertainty
that can
exist between cmp_clk and dr_clks. A discussion on the procedure of
determining
the positions appears in the AAppendix A.1 – Sync Pulse Design
Procedure. There
Chapter 5 Clock Control Unit (CCU) 5-25
are several documents detailing the sync pulse schemes and timing
budgets that
have been created to ensure robustness. An example of the positions of
the dr sync
pulses is shown in FIGURE 5-15.
FIGURE 5-15 Sync Pulse Example for fCMP:fDR = 11:4
The convention is to describe the sync pulse position in terms of cmp
clk phases,
with phase 0 being set to the nominal alignment of cmp and dr clocks.
The sync
pulse positions at the point of domain crossing are given in TABLE
5-6.
TABLE 5-6 DR<->CMP Sync Pulse Positions
CMP<->DR Transfer Edge Transfer phase
(normalized for four dr=2pi)
K - > clk cycles K - > clk cycles
N M Meff N/M 0 1 2 3 0 1 2 3
8 4 1 2.00 1 1 1 1 1 3 5 7
9 4 4 2.25 1 3 6 8 1 3 6 8
10 4 2 2.50 1 4 1 4 1 4 6 9
11 4 4 2.75 1 4 7 10 1 4 7 10
12 4 1 3.00 1 1 1 1 1 4 7 10
13 4 4 3.25 2 5 8 11 2 5 8 11
14 4 2 3.50 2 5 2 5 2 5 9 12
15 4 4 3.75 2 6 9 13 2 6 9 13
16 4 1 4.00 2 2 2 2 2 6 10 14
17 4 4 4.25 2 6 11 15 2 6 11 15
18 4 2 4.50 2 7 2 7 2 7 11 16
5-26 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 •
May 2008
5.4.5 CMP/SYS Pulses
There are a pair of sync pulses between CMP and SYS_CLK strictly for
the RST unit.
These pulses are not staged on the global clock tree, and not taken in
through cluster
headers. However, to account for fanout, the signals are flopped twice
inside the
RST cluster. The scheme relies on the RST block being placed close to
the CCU; there
is tolerance built in for skew between the CMP and SYS_CLK up to a
couple of CMP
cycles.
The active position of the sync pulse (“1” on rising edge of cmp_clk)
will be on
phase two of l2clk. This will provide ample margin, > 1 fast cmp cycle
for setup or
hold. Illustrations of data transfers in both directions are shown in
FIGURE 5-16. For
quantification of the amount of margin available, refer to Appendix A.
1 – Sync Pulse
Design Procedure.
19 4 4 4.75 2 7 12 17 2 7 12 17
20 4 1 5.00 2 2 2 2 2 7 12 17
21 4 4 5.25 3 8 13 18 3 8 13 18
TABLE 5-6 DR<->CMP Sync Pulse Positions (Continued)
CMP<->DR Transfer Edge Transfer phase
(normalized for four dr=2pi)
K - > clk cycles K - > clk cycles
Chapter 5 Clock Control Unit (CCU) 5-27
FIGURE 5-16 Domain Crossing using Sync Pulses in RST

Reset signals are distributed across all logic digital designs.

Weng

 

[rickman]

On Mar 19, 5:31 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote:

[Weng]

there are 6 types of
reset signals, a situation much more complexer than we think.
Ok, go ahead and tease us!  Or are you going to share with us what the
six types are?

1. Reset that is asserted at the right time,
   but has the wrong polarity, thus holding the design
   in reset throughout your test.
2. Reset with the right polarity that is not asserted
   reliably at power-up, because you were too cheap
   to spend $0.70 on a power monitor/watchdog chip.
3. Reset that is triggered at random times during
   operation because it is laid out on the PCB too
   close to a data bus.  Capacitive coupling causes
   reset to be momentarily asserted when more than
   80% of the data lines transition simultaneously.
4. Reset that is asserted correctly, but is released
   too close to a clock edge and causes the design
   to go into an illegal state because some flops
   respond to the clock and others don't.
5. Reset of a counter, used by a designer who thought
   it would be a cool way to make the counter go back
   to zero when it overflows some programmed limit.
6. Reset that is triggered by the operation of a
   system-level watchdog.  It causes the CPU to stop
   operating roughly a millisecond before emitting
   the debug message that would have allowed you
   to diagnose the problem.

Just in case you thought I was fooling, I should point
out that I have had to debug and correct each of these
at some point in my career.  One or two of them were
someone else's fault
--
Jonathan Bromley

Then aren't there at least 7 types of reset? You need to include one
that actually works as expected... or have you never found that one in
practice ;^)

Rick

 

[Andy Peters]

On Mar 19, 6:32 am, rickman <gnu...@gmail.com> wrote:

Yes, it was a typo... in other words, a mistake...  Why do they call
it a "typo".  It was a mistake regardless of how you categorize it.

"typographical error," in other words, a mistake made by the
typesetter, back in the days when such jobs existed.

-a

 

[Otto Bahn]

"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote

I keep waiting for some poster to do a J-K flip flop.

Here's an interesting shibboleth: In some electronics design professional
circles they aren't ever called "flip-flops", and doing so marks one as an
outsider.

I guess the old joke lyric "I got a brand new TTL cookbook,
you got the brand new C" is looking pretty dated.

--oTTo--

 

On Tue, 30 Mar 2010 20:53:05 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

In comp.lang.verilog Otto Bahn <Ladybrrane@grointohell.com> wrote:
"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote

I keep waiting for some poster to do a J-K flip flop.

Here's an interesting shibboleth: In some electronics design professional
circles they aren't ever called "flip-flops", and doing so marks one as an
outsider.

I guess the old joke lyric "I got a brand new TTL cookbook,
you got the brand new C" is looking pretty dated.

And when was it that the beach wear started to be called flip-flops?

We called rubber beach sandals "flip-flops" starting when they were
first sold in the U.S., in the late 1950s or early 1960s.

BW

 

[Sue...]

On Mar 30, 3:10 pm, Jonathan de Boyne Pollard <J.deBoynePollard-
newsgro...@NTLWorld.COM> wrote:

I keep waiting for some poster to do a J-K flip flop.

Here's an interesting shibboleth:  In some electronics design
professional circles they aren't ever called "flip-flops", and doing so
marks one as an outsider.

Even the water-proof variety is vulnerable
to pop-tops. Professionals call them
"multivibrators" but any cave man or beach-bum
can tell you it takes more than one shot of
tequila to sustain oscillation in that mode.

Sue...

 

[glen herrmannsfeldt]

In comp.lang.verilog Otto Bahn <Ladybrrane@grointohell.com> wrote:

"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote

I keep waiting for some poster to do a J-K flip flop.

Here's an interesting shibboleth: In some electronics design professional
circles they aren't ever called "flip-flops", and doing so marks one as an
outsider.

I guess the old joke lyric "I got a brand new TTL cookbook,
you got the brand new C" is looking pretty dated.

And when was it that the beach wear started to be called flip-flops?

I haven't yet tried to explain to my daughter that when I was
her age that flip-flops were electronic circuits.

One of my first desoldering projects was what I believe were
flip-flops from an IBM computer, though with the vacuum tubes
removed. It was a device with two tube sockets, some resistors
and capacitors, and then plugged into a tube socket. It might
have been a flip-flop for the IBM 701 or 704. (Probably would
be valuable today, but I got them from a surplus electronics store.)

-- glen

 

[Evan Kirshenbaum]

barbara@bookpro.com writes:

On Tue, 30 Mar 2010 20:53:05 +0000 (UTC), glen herrmannsfeldt
gah@ugcs.caltech.edu> wrote:

In comp.lang.verilog Otto Bahn <Ladybrrane@grointohell.com> wrote:
"Jonathan de Boyne Pollard" <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote

I keep waiting for some poster to do a J-K flip flop.

Here's an interesting shibboleth: In some electronics design
professional circles they aren't ever called "flip-flops", and
doing so marks one as an outsider.

I guess the old joke lyric "I got a brand new TTL cookbook,
you got the brand new C" is looking pretty dated.

And when was it that the beach wear started to be called flip-flops?

We called rubber beach sandals "flip-flops" starting when they were
first sold in the U.S., in the late 1950s or early 1960s.

The OED cites it to 1958 in the footwear sense, 1935 in the hardware
sense.

--
Evan Kirshenbaum +------------------------------------
HP Laboratories |Other computer companies have spent
1501 Page Mill Road, 1U, MS 1141 |15 years working on fault-tolerant
Palo Alto, CA 94304 |computers. Microsoft has spent
|its time more fruitfully, working
kirshenbaum@hpl.hp.com |on fault-tolerant *users*.
(650)857-7572

http://www.kirshenbaum.net/