Clock Edge notation

[Peter Alfke]

Spartan is much cheaper and does not have all the bells and whistles of
Virtex.
So you have to knit your own, or grab a core.
Complexity depends on synchronous/asynchronous choice, and on max clock
rate.
At a slow speed, you can time share read and write.
Many choices...
Peter Alfke

 

[Peter C. Wallace]

On Mon, 17 Oct 2005 12:32:48 -0700, Dave Pollum wrote:

Peter Alfke wrote:
Let me correct this:
The addressing depth of Virtex-4 FIFOs is 512, 1024, 2048, or 4096
locations. The word "byte" is meaningful only for the 2048 x 9
configuration.
The FULL flag goes active one write clock cycle after the FIFO has been
filled. That means, in a continuous write situation, the last written
entry will be lost. That's why I recommend using the ALMOST FULL flag
instead of the FULL flag.
EMPTY does not have this problem. It goes active on the same read clock
edge that is reading the last piece of data out of the FIFO. EMPTY
then goes inactive again after a data entry has been written into the
FIFO and the internal signal hes been re-synchronized to the read
clock, which takes a few read clock cycles. This asymmetric behavior
assures that the EMPTY flag is appropriately extremely fast in stopping
any further erroneous reads, but is more "relaxed" in allowing the
reading to restart again. Note that this read latency only occurs after
the FIFO had gone empty. If anybody has questions about the Virtex-4
FIFO, I am the right person to ask. I have designed FIFOs, on and off,
for over 35 years... Peter Alfke, Xilinx Applications

So Peter, what do those of us with lowly Spartan-II FPGA's do if we want
say, a 16x9 FIFO?
-Dave

A very small 16 by N sync FIFO is easy in the SpartanII using N SRL16E's
(and a 5 bit counter)

Peter Wallace

 

[raulizahi@gmail.com]

Hi Jim,

Xilinx synchronization FIFO problems show in just a few minutes. There
used to be a problem with the previous release of their core generator,
the latest one works fine in the lab. Just make sure you always have
the latest version of the core generator to avoid headaches in the lab
that would not show in simulation.

RAUL

 

[Gabor]

Peter C. Wallace wrote:

On Mon, 17 Oct 2005 12:32:48 -0700, Dave Pollum wrote:



So Peter, what do those of us with lowly Spartan-II FPGA's do if we want
say, a 16x9 FIFO?
-Dave

A very small 16 by N sync FIFO is easy in the SpartanII using N SRL16E's
(and a 5 bit counter)

Peter Wallace

I think the thread was about async FIFO. For this SRL16's are of no
use. Your best bet is the COREgen FIFO using distributed memory for
shallow (x15 or x31) FIFO's or block memory for deeper ones.

 

One common situation where patents have duplicate titles is simply that
the patents cover (in a very general sense) similar subject matter.
For example if you and I were independently working on ergonomic
keyboard, there would be nothing unusual that we both file patent
applications with the title "Ergonomic Keyboard."

A second reason is that a patent application may spawn several patents.
For example, if I apply for a patent on my ergonomic keyboard and half
the claims are allowed, I may choose to go ahead and pay the fees and
have the patent granted; meanwhile I could file a continuation
application and pursue the remaining claims. It is likely that both
patents would have the same title.

Regarding the cases you cited, it is possible that the lawyer erred,
more likely however the client and the lawyer decided to take what the
patent office offered, and have a first patent issue. The client and
lawyer would have also agreed to file an additional application. Yes,
multiple patents generally cost more than a single patent, but it still
may be good business strategy to go for multiple patents. In some
cases the patent office requires that only one set of claims be
examined, if you want the other claims you have to file another
application; which is likely to have the same title.

If you want to know more about what happened with those particular
patents go to http://portal.uspto.gov/external/portal/pair , and look
up the prosecution history.

This answer to your question about when to file a provisional / regular
application and if a c-i-p make sense depends on the details of the
situation. One strategy is to file a provisional application with
information X as soon as you can write a good description. When
information Y becomes available, then file a provisional with a
description of X+Y. When you have information Z, then file a
provisional application with X+Y+Z. You just have to keep in mind that
provisional applications lapse after one year. So if you wait to file
a regular application for X until more than 1 year after filing
provisional X, then you have to rely on the priority date of the X+Y
provisional application(assuming that less than one year has passed
since filing provisional X+Y).

All of the above is a general discussion of U.S. patent law, and not
intended as legal advice for any particular situation.


Richard

 

[Martin Thompson]

"sudhi" <sudhi.kadri@gmail.com> writes:

The best solution is not to use integers for counters. Use
std_logic_vector(WIDTH-1 DOWNTO 0)

I'd use "unsigned" (along with numeric_std) myself - saves on a lot of
conversions! It's the right tool for the job.
Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

 

[Marcus Harnisch]

Hi Calvin,

"Calvin" <cathai@netzero.net> writes:

If you have used these 2 vhdl debugging tools, please let me know your
likes/dislikes for each tool.

Is one better than the other or are they complement each other ?

I've been using Novas Verdi (Debussy + add-ons) for quite a while
until about a year ago (switched workplace). In fact I was beta tester
for their VHDL support which was under development then (and might
still be, dunno).

I have not used Modelsim dataflow extensively (partly due to usability
issues in the past) and I am not familiar with their current set of
features.

Personally, I preferred the Debussy UI (not necessarily the looks of
it though over Modelsim's *a lot*. Navigating through the code
(tracing networks across files) was a snap. The active annotation
feature is nice to have, although I might confuse which features were
provided by add-ons only.

I also liked Novas' way of license management, which allowed us to
keep a design open forever and only checked out a license if the tool
has actually been used. After a certain time of silence (half hour?),
the license would be released again. Not sure if this is still the
case though.

Another nice feature (nSchema/Verdi only, but worth noting) is the
ability to pull in Synopsys symbol libraries (maybe others). That
turned the tool into a very fast and powerful netlist browser.

Smooth Integration with nLint (if that applies to you) is also a plus.

Year's end coming closer, you might want to bug your Novas sales
person about Verdi rebates. Everyone needs to pull in their sales.

To answer the second question: IMHO, Debussy's feature set is better
but comes with a higher price tag. Whether buying an additional tool
is worth your money is a question only you can give the answer for.

I don't think both tools complement each other.

Hope that helps,
Marcus

 

[Ajeetha]

Hi,
Though I've not used Debussy, I'm told that its "Active Driver"
feature is a very valuable one - I'm not aware of any simulator
(MTI/NC/VCS) supporting it as of now - comments anyone? This can be one
of the key differentiators.

In general, Debussy should be great - that's their bread-and-butter. A
simulator has to do several things plus good Debug - I believe all of
them are doing a decent job, given their focsu is simulation and the
art of debug is a complex problem to solve on its own.

Ajeetha
www.noveldv.com

 

[Mike Treseler]

Calvin wrote:

Re: modelsim dataflow vs novas debussy
Is one better than the other or are they complement each other ?

I sometimes use modelsim dataflow to debug
testbench signal driver fights.

Have not used debussy, but it
looks very similar on their web page --
it's an alternative, not a complement.

Since I use a single process module style,
and no module signals, I find that I use
the dataflow feature very rarely for
debugging my own code.

-- Mike Treseler

 

[Andy]

Used properly, integers can and do work better than vectors for
counters.

Operator precedence forces evaluation of the MOD operator prior to the
+ operator, so what he is getting is:

count <= count + (1 mod length); -- (1 mod length) is always 1

When what he wants is:

count <= (count + 1) mod length;

So should it be written.

Integer counters, especially local ones that have no impact on
interface data types, are particularly useful for several reasons:

1. They simulate MUCH faster (even with the MOD operation)

2. They allow access to carry chain much more easily:
variable count : natural range 0 to 7;
....
if count - 1 < 0 then -- implies sign bit (i.e. carry bit) = 1
count := start_count;
do_something;
else
count := count - 1; -- shared operation with above comparison
do_something_else;
end if; -- don't try this with unsigned!!!

3. They don't ALLOW a rollover unless you planned for it. Addition
NEVER rolls over; only a limitation of the hardware implementation
does. I often do not put in rollover handling where I should not get
it, and if I ever do during simulation, it will let me know about it.
The synthesized hardware, obeying the limitations of the
implementation, will rollover, but that may not be what you wanted...

4. Creating arithmetic circuits with differently sized operands and
results is much easier with integer types.

5. Out of range values are optimized away in comparisons:
variable count: integer range 0 to 5;
....
if count = 2 then -- no need to check count(2), optimized away
-- more readable than: if count(1 downto 0) = "10" then

6. Case statements don't need "when others =>" if you've covered all of
the (legal) numerical values.


Andy Jones


Martin Thompson wrote:

"sudhi" <sudhi.kadri@gmail.com> writes:

The best solution is not to use integers for counters. Use
std_logic_vector(WIDTH-1 DOWNTO 0)

I'd use "unsigned" (along with numeric_std) myself - saves on a lot of
conversions! It's the right tool for the job.
Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

 

[Martin Thompson]

"Andy" <jonesandy@comcast.net> writes:
<lots of good stuff snipped>

Andy,

I agree with all of those points (especially getting simulation checks
on wraparounds you didn't want!).

All I intended to point out was that doing arithmetic on slvs is not
the right thing

Cheers,
Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

 

[Ralf Hildebrandt]

krby_xtrm wrote:

containing both rising and falling edge of clock??

Don't use both edges - especially not for one flipflop. There is no
standard way to synthesize this, because most libraries don't have such
a flipflop and therefore

process(reset,clock)
begin
if (reset='1') then
-- reset
elsif rising_edge(clock) then
-- ...
elsif falling_edge(clock) then
-- ...
end if;
end process;

cannot be synthesized by the most synthesis tools.

If you are really certain, that you definitely need a dual-edge
flipflop, you may use the thing I call a pseudo dual-edge flipflop:
http://groups.google.de/group/comp.lang.vhdl/browse_frm/thread/105a0828de226ed7/73b9f78d5efc3cf2?lnk=st&q=pseudo+dual+edge+flipflop+group:comp.lang.vhdl&rnum=1&hl=de#73b9f78d5efc3cf2

I can't think of any (good) reason to use this for a state machine. Use
the doubled clock instead and divide the clock for the other parts, that
don't need the faster clock.

Ralf

 

[krby_xtrm]

actually it's a Dual_State_machine...

one state machine operates at rising edge and the other one is at the
falling edge...
both have different output lines that are ANDed together to produce a
sigle output line.

what i need to do is to make a dual_state machine in Active-HDL State
machine editor, ofcourse i have made it with Manual coding but i need
to learn how to make it on State Machine editor, to promote
productivity later on...

 

[Ralf Hildebrandt]

krby_xtrm wrote:

actually it's a Dual_State_machine...

one state machine operates at rising edge and the other one is at the
falling edge...
both have different output lines that are ANDed together to produce a
sigle output line.

What's the reason for this? Remember, that this results in higher timing
requirements and may result in problems of the synthesis tool
recognizing the timing paths.

Sorry, I don't have a hint how to solve you problem, but I just want to
remember you, that using both clock edges is difficult and should be
avoided as long as possible.

Ralf

 

[krby_xtrm]

not actualy, here a sample of what i think:

-------- UPPER SECTION A: ------------------
process(clk)
begin
....
if rising_ege(clk) then
pr_state1 <= nx_state1;
...

end process;
----------UPPER SECTION B: -------------
process(clk)
begin
....
if falling_edge(clk) then
pr_state2 <= nx_state2; -- traverse states
....
end process;
-----------------------------------------------------
--- STATE MACHINE A
---------------------------------------------------
process(pr_state1)
begin
case pr_state1 is
when state1 =>
outp1 <= '1';
nx_state1 <= state2;
when state2 =>
....
end process;
-------------------
-----------------------------------------------------
--- STATE MACHINE B
---------------------------------------------------
process(pr_state2)
begin
case pr_state2 is
when state1 =>
outp2 <= '1';
nx_state2 <= state2;
when state2 =>
....
end process;
-------------------


-- later....

final_output_line <= outp1 AND outp2; -- here

regards,
krby_xtrm

 

[Mike Treseler]

krby_xtrm wrote:

i have made it with Manual coding but i need
to learn how to make it on State Machine editor, to promote
productivity later on...

I wouldn't worry about that.

The standard motivation to use such an editor
is to learn how to write HDL code to
update state and output registers.
It looks like you have figured it out.

I *would* worry about using both clock
edges, but you'll figure that out too.

-- Mike Treseler

 

[Mariusz]

krby_xtrm wrote:

not actualy, here a sample of what i think:

-------- UPPER SECTION A: ------------------
process(clk)
begin
...
if rising_ege(clk) then
pr_state1 <= nx_state1;
..

end process;
----------UPPER SECTION B: -------------
process(clk)
begin
...
if falling_edge(clk) then
pr_state2 <= nx_state2; -- traverse states
...
end process;
-----------------------------------------------------
--- STATE MACHINE A
---------------------------------------------------
process(pr_state1)
begin
case pr_state1 is
when state1 =
outp1 <= '1';
nx_state1 <= state2;
when state2 =
....
end process;
-------------------
-----------------------------------------------------
--- STATE MACHINE B
---------------------------------------------------
process(pr_state2)
begin
case pr_state2 is
when state1 =
outp2 <= '1';
nx_state2 <= state2;
when state2 =
....
end process;
-------------------


-- later....

final_output_line <= outp1 AND outp2; -- here

regards,
krby_xtrm

krby_xtrm,

It is very simple. Create 2 machines on one sheet (FSM | New Machine).
Then call Properties for the machine you have created and on the General
tab of Machine Properties you will be able to specify the active edge of
the clock for each machine independently.

By default Active-HDL's State Machine Diagram editor uses 'event and
value for clock detection. Use the FSM | Code Generation Settings to
choose the rising_edge/falling_edge function.

Regards,
Mariusz

Regards,
Mariusz

 

[Stephane]

John Penton wrote:

Davy wrote:

Hi all,

reg[7:0] register;
The register contains data like
[0 0 0 1 0 1 0 1]
And I want to know the number of the zeros before the first 1
(in this example is 3 zeros).

How to do this in a combinational logic?


With a priority tree:

if (reg[7:0] == 8'b00000000)
clz = 3'h8;
else if (reg[7:1] == 7'b0000000)
clz = 3'h7;
else if ...

You can play some tricks to make it faster - particularly useful if your
register is bigger than 8 bits. It will always be quite large.

John

This would waste a lot of resources if the reg is large... I would have
done it sequentially with a counter!

(and cross-posting is baaaaad ;-)

 

[Arie de Muynck]

I found on the web some discussions, with this as the best observation:

I'm very sure that there is some sort of electronic circuit in there
somewhere (yet another "thick base"). If you notice, the trick is

performed, so that every time the switches are thrown, the lights light up
in the order they are in the sockets, from right to left. (This is using
the Carson performance as reference).
So, I'd assume that it's some sort of circuit so that no matter what
switch is thrown, the first goes on, then the second switch thrown turns
on the second one, as so forth.


Which sounds like some very simple sequential logic.

Also, suggestions were made that tracking the order in which lamps were
removed, then replaced, allows the unit to "memorize" the positions. But
that in itself would not explain the final part of the trick with the
exchanging of the switch caps, in that part the operation (sequencing) of
the switches must be special.

--
Regards,
Arie de Muynck

 

[Weng Tianxiang]

Hi,
This is a search list about how to count leading zero for ASIC.

Using the patent number, you can download full content of a patent from
US Patent Office website:
http://patft.uspto.gov/netahtml/search-bool.html.

Those listed must be the most advanced algorithm. Others may be at
amateur level.

Weng


Results of Search in 1976 to present db for:
TTL/"leading zero": 13 patents.
Hits 1 through 13 out of 13
PAT. NO. Title
1 6,779,008 Method and apparatus for binary leading zero counting with
constant-biased result
2 6,654,776 Method and apparatus for computing parallel leading zero
count with offset
3 6,594,679 Leading-zero anticipator having an independent sign bit
determination module
4 6,477,552 Device and method for performing a leading zero
determination on an operand
5 6,205,461 Floating point arithmetic logic unit leading zero count
using fast approximate rounding
6 5,993,051 Combined leading one and leading zero anticipator
7 5,974,432 On-the-fly one-hot encoding of leading zero count
8 5,875,123 Carry-select adder with pre-counting of leading zero
digits
9 5,844,826 Leading zero count circuit
10 5,241,490 Fully decoded multistage leading zero detector and
normalization apparatus
11 5,204,825 Method and apparatus for exact leading zero prediction
for a floating-point adder
12 5,111,415 Asynchronous leading zero counter employing iterative
cellular array
13 4,247,891 Leading zero count formation