need a cheap student edition FPGA

"Miller2000" <miller2000@walla.com> wrote in message
news:1115646489.259016.274670@f14g2000cwb.googlegroups.com...
Hi Mike!

The? ?customer? ?wants? ?that? ?there? ?will? ?be? ?no? ??"?clock?"??.?

I? ?want? ?to? ?latch? ??"?input? ??8?? ?bit?"?? ?into? ?a? ?flip?-?flop?
?when?
??"?posedge? ?of? ?latch?8??"?? ?OR? ??"?negedge? ?of? ?latch?8?tag?"??
??,?
so? ?it? ?is? ?external? ?signal? ?that? ?make? ?the? ?latch? ?to? ?the?
?flip?
?flop?.?
<snip>

You could use two register sets: one "clocked" on (posedge latch8) and the
other on (negedge latch8tag) AS LONG AS the two signals won't transition too
close to each other. You then need a little circuit to select which of the
two register sets to use, perhaps as simple as a set/reset NAND latch. This
sounds like an UGLY task.
 
A single always @(posedge clk) block can only infer flip-flops on a single
clock edge, and a single flop can only have one "clock". Therefore, you need
to define you complex clock (temp_clk, which is the combination of the two
latch signals) outside the always blocks, and then have separate always
blocks to infer the flops on the three clock edges; the posedge temp_clk,
the negedge temp_clk and the posedge latch16 (shown below).


assign temp_clk = (latch8 ^ ~latch8tag)

always @(posedge temp_clk)
ff1 <= in8;

always @(negedge temp_clk)
ff2 <= in8;

always @(posedge latch16);
out <= {ff1,ff2};

(you can add the appropriate reset conditions as you want them).

However, this is very messy stuff. First, you must ENSURE that the "unused"
clock is idle around the pulses of the used clock; if you want to use
latch8, then latch8tag must be 1; if you want to use latch8tag, then latch8
must be 0. If you have edges on both latch8 and latch8tag, then you have the
risk of runt clock pulses...

Second, it uses a clock that doesn't come directly from a pin. In an ASIC,
this is a pain (having a gate in your clock tree). In an FPGA, it forces you
to use "general" resources for the generation of a clock, which will make
the setup and hold times of ff1 and ff2 with respect to the two clocks
somewhat variable (they can change each time you place and route the FPGA).

Avrum


"Miller2000" <miller2000@walla.com> wrote in message
news:1115654460.046101.38960@o13g2000cwo.googlegroups.com...
Hi? ?Avrum? ??!?

Tanks? ?for? ?the? ?replay?.?

What? ?the? ?customer? ?wants? ?is? ?your?
?option? ??1??:?
?1??)?? ?capture? ?the? ?most? ?significant?
??8?? ?bits? ?on? ?the? ?rising? ?edge?
?of? ?latch?8??,?? ?capture? ?
the? ?least? ?significant? ?bits? ?on? ?the?
?falling? ?edge? ?of? ?latch?8??,?? ?and?
?the? ?
concatenate? ?the? ?two? ?together? ?on?
?latch?1??6??.?? ?This? ?would? ?look?
?like? ?a? ?relatively? ?
normal? ?double? ?data? ?rate? ?type? ?protocol?
?

BUT? ?the? ?customer? ?wants? ?that? ?he?
?have? ?an? ?option? ?to? ?do? ?the? ?same?
?as? ??(??1??)?
with? ?latch?8?tag? ?that? ?it? ?is? ?the?
?activate? ?opposite?:?? ??"?falling? ?edge?
?of? ?latch?8?tag?"?? ?then? ??"?rising?
?edge? ?of? ?latch?8?tag?"?

The? ?customer? ?will? ?not? ?use?
?latch?8?? ?and? ?latch?8?tag? ?together?!?

That?'?s? ?the? ?reason? ?I? ?use?
?temp?1?? ?&? ?temp?2?? ??:??
??(?XOR? ?the? ?two? ?latches?)?
? ?assign? ?temp?1?? ??=?? ?latch?8??
??^?? ?latch?8?tag?;?? ?
? ?assign? ?temp?2?? ??=??
??~??(?latch?8?? ??^??
?latch?8?tag?)??;?? ?
? ?always? ?@?(?negedge? ?temp?1?? ?or?
?negedge? ?temp?2?? ??.??.??.??.?

Thanks
miller?2??0??0??0?
 
A multi-cycle path is a path that is allowed multiple clock cycles for
propagation. Again, it is a path that starts at a timing startpoint and ends
at a timing endpoint. However, for a multi-cycle path, the normal constraint
on this path is overridden to allow for the propagation to take multiple
clocks.

In the simplest example, the startpoint and endpoint are flops clocked by
the same clock. The normal constraint is therefore applied by the definition
of the clock; the sum of all delays from the CLK arrival at the first flop
to the arrival at the D of the second clock should take no more than 1 clock
period minus the setup time of the second flop and adjusted for clock skew.
By defining the path as a multicycle path you can tell the synthesis or STA
tool that the path has N clock cycles to propagate; so the timing check
becomes "the propagation must be less than N x clock_period, minus the setup
time and clock skew". N can be any number greater than 1.

One place where you might see a multi-cycle path (MCP) is when you have a
"complex" combinational path, but it is only needed to create an output
every second clock (often an arithmatic operation). If coded correctly...

always @(posedge clk)
begin
if (every_other_clock)
begin
in <= new_inputs;
out <= complex_function(inputs);
end
end

where the signal every_other_clock is high every second clock, then the
paths from in -> out can be defined as a multicycle paths. Again, the
synthesis/STA cannot infer the MCP property, it is up to the user to define
the constraint using a multi_cycle_path directive during synthesis/STA.

Another place where you might see it is when you are doing clock crossing
from two closely related clocks; i.e. from a 30MHz clock to a 60MHz clock,
assuming the two clocks are from the same clock source (i.e. one is the
divided clock of the other), and the two clocks are in phase. The normal
constraint in this case is from the rising edge of the 30MHz clock to the
nearest edge of the 60MHz clock, which is 16ns later. However, if you have a
signal in the 60MHz domain that indicates the phase of the 30MHz clock, you
can design a circuit that allows for the full 33ns for the clock crossing

always @(posedge clk)
begin
if (30MHZ_is_low)
flop60 <= flop30;
end

then the path from flop30 -> to flop60 is a MCP (again with N=2). The
generation of the signal 30MHZ_is_low is not trivial, since it must come
from a flop which is clocked by the 60MHz clock, but show the phase of the
30MHz clock...

Another place would be when you have different parts of the design that run
at different, but related frequencies. Again, consider a circuit that has
some stuff running at 60MHz and some running on a divided clock at 30MHz.
Instead of actually defining 2 clocks, you can use only the faster clock,
and have a clock enable that prevents the clocks in the slower domain from
updating every other clock

always @(posedge clk60)
begin
if (enable_30)
begin
[operations on the flops in the "30MHz domain"]
end
end

then all the paths from the "30MHz" flops to the "30MHz" flops can be MCP.
This is often done since it is usually a good idea to keep the number of
different clock domains to a minimum.

Another place would be when dealing with a bus protocol that has an inherent
MCP in it. For example, if you have a bus protocol where (say) the address
shows up on the clock before the write data and stays valid for both clock
cycles, then you could declare the address an MCP to the destination flops.
Assuming write_strobe is only asserted during the second of the two phases
and the code reads

always @(posedge clk)
begin
if (write_strobe && (address == MY_ADDRESS))
my_data <= data_in;
end

where MY_ADDRESS is the address (a constant) for the register that is stored
in the flops my_data, then there is a MCP from address -> my_data. Note: in
all these cases, there are also paths that are NOT MCPs; in this example,
the paths from write_strobe->my_data, and the paths from data_in to my_data
are NOT muti-cycle - they are regular single cycle paths.

Again, this is not exhaustive, but gives some examples of MCPs.

Also, it should be pointed out that MCPs should be avoided where possible,
since they are easy to get wrong, and can often be coded around... In the
first case, one would normally attempt to pipeline the long arithmatic
operation rather than use MCPs. In the second case, the clock crossing
should probably be attempted in the 16ns, rather than allow the full 33MHz -
just because you CAN take 33ns, doesn't mean that you NEED 33ns. In the
third case, the same argument applies; if the technology is fast enough and
the logic simple enough, don't declare the paths as MCP - this will
overconstrain the paths, but if that doesn't cause too much area growth (or
difficulty during synthesis), then let it be. The same is true of the last
case - if you can easily meet timing without defining the MCP, then it is
probably safer not to do so...

Avrum

"Chloe" <chloe_music2003@yahoo.co.uk> wrote in message
news:1115340963.323459.293420@f14g2000cwb.googlegroups.com...
To everyone who replied my post:

Thanks very much for all the much-needed information, especially to
Avrum, who explained false path to me very well.

What about multiple cycle paths? What are the "conventional" examples
of these paths?

Thanks very much in advance.

Regards,
Chloe
 
Hi,
Take a look at $VCS_HOME/doc/examples/vcm

There are 3 example IIRC. In a nut-shell, add the following to your regular
vcs invocation:

-cm line+cond+fsm+tgl+path

HTH
Sri

--
Srinivasan Venkataramanan
Co-Author: SystemVerilog Assertions Handbook, http://www.abv-sva.org
Co-Author: Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition.
http://www.noveldv.com
I own my words and not my employer, unless specifically mentioned
"Direbert" <chlin007@hotmail.com> wrote in message
news:1115453563.885282.193170@f14g2000cwb.googlegroups.com...
BTW...
Examples of scripts for Code-Coverage/Design-Coverage, to be specific.

Thanks

Direbert wrote:
Dear Group

Is there a good place that one can download Synopsys VCS Tutorial,
including examples of scripts?

Thank you so much

Dierbert
 
"John_H" <johnhandwork@mail.com> wrote in message
news:Z05ge.12$p%5.134@news-west.eli.net...
For synthesis, never break out a register into two always blocks. You
have
a (posedge reset) for many regs that are later assigned in non-clocked
always blocks. I don't know how a synthesizer would BEGIN to guess what
you're doing.

Ignoring the reset for the moment, the outputs based on the result count
are
going between live and latched states. Note that the transition from 1 to
2
can look like a 0 or a 3 for a moment bacause the two bits cannot
statistically change at *exactly* the same time. If you insist on using a
latch structure with a result counter, you will need to change that
counter
to a Gray counter so there IS no confusion on the value when you change
from
one count to another: it cannot be misconstrued for a moment.

Are you *sure* the exclusive-or in the temp_clock gives you what you want?
What happens if latch 8 changes multiple times while latch8tag is steady
state?


I worry for your customer.
I think the "customer" should run ... and quickly. :)
 
DANGER you're assigning r_counter_rst and clk_en (your error message
signals) im multiple always blocks clocked by both temp_clk and counter_clk.
STOP IT! Keep assignments for any one register in one always block - do not
split it up into multiple blocks.


"Miller2000" <miller2000@walla.com> wrote in message
news:1115794509.549190.77910@g44g2000cwa.googlegroups.com...

<original message excluded for brevity>
 
fpgabuilder wrote:
Hi Folks,

I am using Altera's LPM FIFOs. These are deep fifos and was wondering
if there are any techniques that people follow to initialize the rd/wr
pointers in the fifo so that I can quickly simulate the overflow
condition. I use modelsim pe.
You could infer the same FIFO from code.
Simulating the code instead of using Altera's netlist
will speed up your simulation.

Or you could test overflow on a smaller FIFO.

-- Mike Treseler
 
A quick google search on "cube root algorithm" brought me to:
http://mathforum.org/library/drmath/view/52605.html

If you've implemented the square root in logic, you'd know how easy it is to
do things in binary. The task now would be to push the new algorithm into
binary.

If you find yourself stuck after several hours of working on it, let me know
and I'll diddle with it; these kinds of algorithms ar fun for me.


<john.deepu@gmail.com> wrote in message
news:1115976732.825982.198420@g49g2000cwa.googlegroups.com...
Hi ,
Can anyone give me some clues regarding how to implement cuberoot
function in RTL for synthesis.

thanks
 
john.deepu@gmail.com wrote:
Hi ,
Can anyone give me some clues regarding how to implement cuberoot
function in RTL for synthesis.

thanks

Here's an algorithm based on derivative convergence that I think might
be easy to implement as a multi-cycle logic to solve for cubic roots:

1. You want to solve for an equation x^3 = A, which is the x-axis
intercept of -x^3 + A = 0. Let f(x) = -x^3 + A. Also assume A is
positive number (the negative number has the same root, just different
signs)

2. The first derivative of that function is f'(x) = -3x^2, (we don't
need to actually do the derivative in HDL, just use the derivative
fucntion as given).

3. In order to start the interative convergence, we must pick an initial
guess. You can pick whatever number you want, such as A/2. You can even
start with 2^(log2(A)/3), which is pretty much just 1/3 of A's binary
length. Or you can use a fixed number such (1/3)^2 because that's when
the derivative is -1. No matter what initial number you choose,
eventually you WILL get to the root, as there is only one root and
function f is monotonic.

4. The iteration starts now. Calculate y=f(x)=-x^3+A, let's call this
pair of x and y (x1,y1). Smililar, calculate y'=f'(x)=-3x^2, call it y'1.

5. Now you have a point and a slope, find the x-axis intercept for it,
which is the root to the equation (0-y1)/(X-x1) = y'1. Of course, you
have already solved it on paper, X = x1 - y1/y'1

6. You have finished one iteration, take the value of X and start the
iteration again, until y=f(x)=-x^3+A is close enough to 0. You decide
when to stop.

Each of the iteration contains 3 multiplies, 1 division, and 2
additions. The convergence is quite fast, although I haven't assessed
the average number of iterations required for an arbitraty precision.

Good luck and let me know if anyone knows a faster algorithm.

-jz
 
Allan Herriman wrote:
On Mon, 28 Jun 2004 15:22:24 -0700, Navneet Rao <navneetr@xilinx.com
wrote:


Hi:
Has anybody seen this...

always @ ( * ) begin
......
......
......
end


Yes, this was introduced in the 2001 language revision. Basically it
means that the sensitivity list is all signals that are used within
the block. This is much less error prone than typing a large list of
signals (which can lead to latch behaviour if you leave one out by
mistake).

BTW, it can also be written always *@ begin ... (without the
should be @*
brackets).

Regards,
Allan.
The better way to write it is:
always @* begin
....
end

Because some compilers doesn't know how to deal with (*). Clifford
Cummings wrote in his "The IEEE Verilog-2001 Simulation Tool Scoreboard,"


Even better than the comma separated sensitivity list is the very
concise @* combinational sensitivity list. The @* basically was added to
mean, if the synthesis tool wants it, then so does the simulator! Note
that although, @(*) is also currently a legal form of this sensitivity
list, there is some consideration being made by the Verilog standards
groups to remove support for this form. The problem is that (* is also
the opening delimiter for the new Verilog-2001 attributes, and tool
vendors have complained about the difficulty in distinguishing between
the two. I personally would support removal of the @(*) style, and if
your company writes any in-house tools, adopting a coding standard that
prohibits @(*) will probably make your tool-creation job easier.
Guideline: Use @* for combinational sensitivity lists and do not use
@(*) Some vendors are doing a good job of supporting the @* feature
while one vendor has implemented the SystemVerilog always_comb
statement, which is currently a slight super-set of the @* capability.
It would be nice to have the @* capability implemented universally by
all vendors.

see
http://www.sunburst-design.com/papers/CummingsDVCON2003_V2K1_SimScore_rev1_2.pdf
 
Jason Zheng wrote:

The better way to write it is:
always @* begin
...
end

Because some compilers doesn't know how to deal with (*). Clifford
Cummings wrote in his "The IEEE Verilog-2001 Simulation Tool Scoreboard,"


see
http://www.sunburst-design.com/papers/CummingsDVCON2003_V2K1_SimScore_rev1_2.pdf
I'm one of those compiler writers who had a run in with the syntax,
but unlike some other things in Verilog, it is not ambiguous. I had
to detect "(*)" in the lexical analyzer, and if matched, convert it
to a single '*' token. This prevents "(*" from being interpreted as
the start-of-attribute token. It's a little quirky, but not difficult.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
Julian wrote:
Sorry if this question is too newbie, but I dont't know how to actually do
this. I need to have a two input multiplexer.

For a one input multiplexer I know I can do:

assign my_signal = (when_this_is_true) ? (assign_this_value) :
(if_not_true_this_is_assigned);

But in pseudo code I would like to write:
if one thing is true assign A to my_signal, or if another thing is true
assign B to my_signal else assign C to my_signal. Could I do this with the
simple assign statement?
Or do I have to write a "regular" if-statement?

P.S. The code needs to be syntheziable!

Best Regards
Julian


you can do this with a cascaded ?: statement:

assign my_signal = predicate1 ? a : predicated2 ? b : c

Though it's perfectly legal to use this, I prefer the following:

reg my_signal

always @*
if (predicated1) my_signal = a
else if (predicate2) my_signal = b
else my_signal = c

The latter is a lot easier to understand than the cascaded ?: statement
 
essen_tsai@sis.com (Essen) wrote in message news:<5650dc48.0410210822.3a6e8830@posting.google.com>...
I'm confusing about wire and reg type in verilog.
In case statement, if i replace output "reg" with "wire",
is there different between the result?
Conceptually, a wire is continuously driven by one or
more drivers, such as continuous assignments or gates.
If driven by multiple drivers, this is modeled like a
real hardware wire driven by multiple drivers.

A reg is written to in procedural code, like a variable
in a programming language. It holds its value between
writes. It may be written in many places, and just holds
the last value written.

A wire cannot be assigned in procedural code (i.e. always,
initial, task or function). A reg cannot be driven by a
continuous assignment or gate output.

Originally, regs were intended to represent register
elements in the design. However, it is quite possible to
use coding styles where they are only written by one
always block, and the always block is coded so that it
behaves much like a continuous assignment. In this case,
a synthesis tool will synthesize them into wires, instead
of registers. But that doesn't make them wires; it just
makes them regs being used in a way that mimics wires.
It does add to the confusion of users trying to understand
the differences between them.

Short answer: If you want to write to it in procedural code,
use a reg. This will include all behavioral flip-flop or
latch models. If you want to drive it with a continuous
assignment or gate, use a wire. This will include any time
you need multiple drivers, such as a tristate bus. If you
need to use a synthesis tool, you will have to stick to the
restricted coding style that the tool supports.
 
For synthesis, never break out a register into two always blocks. You have
a (posedge reset) for many regs that are later assigned in non-clocked
always blocks. I don't know how a synthesizer would BEGIN to guess what
you're doing.

Ignoring the reset for the moment, the outputs based on the result count are
going between live and latched states. Note that the transition from 1 to 2
can look like a 0 or a 3 for a moment bacause the two bits cannot
statistically change at *exactly* the same time. If you insist on using a
latch structure with a result counter, you will need to change that counter
to a Gray counter so there IS no confusion on the value when you change from
one count to another: it cannot be misconstrued for a moment.

Are you *sure* the exclusive-or in the temp_clock gives you what you want?
What happens if latch 8 changes multiple times while latch8tag is steady
state?


I worry for your customer.
 
I've been playing around with the algorith in my down time. I haven't
put together verilog but the Excel spreadsheet shows everything flows.

I have the square root implemented with the input load/shift register, a
single registered adder and the result shift register. One result bit
per clock.

I have the cube root implemented with the input shift register, two
adders, two registered adders, and the result shift register. One
result bit per clock. No multiplies!

To get verilog together, one would have to specify the number of input
bits and the number of result bits. To illustrate the square root could
be 4 bits input with results to many decimal points, e.g.
(sqrt(4'h2))<<8==10'h16a for a fixed-decimal result of 8 bits,
approximately 1.41406. A fixed-decimal input could also be used as long
as there are 3n decimal bits; shift 3n left for the input, shift n right
for the result.

As long as this isn't homework, I can provide an excel spreadsheet with
the adders broken out or put together verilog based on in/out port
sizes. A generic verilog module could be parameterized but I don't care
to do that right now - getting the register sizes "just right" for all
cases isn't trivial.

Fun!
- John_H


John_H wrote:
A quick google search on "cube root algorithm" brought me to:
http://mathforum.org/library/drmath/view/52605.html

If you've implemented the square root in logic, you'd know how easy it is to
do things in binary. The task now would be to push the new algorithm into
binary.

If you find yourself stuck after several hours of working on it, let me know
and I'll diddle with it; these kinds of algorithms ar fun for me.


john.deepu@gmail.com> wrote in message
news:1115976732.825982.198420@g49g2000cwa.googlegroups.com...

Hi ,
Can anyone give me some clues regarding how to implement cuberoot
function in RTL for synthesis.

thanks
 
In 1985 we added a square root step opcode (one result bit per clock) to
the multiply, divide, bit reverse, and crc step opcodes already in the
NOVIX 4016, implemented at the time in a 3u gate array. They're all
based on the paper and pencil decimal versions found in an 1890s math
book. I'm glad to see it being addressed in Verilog! Ours went from
forth code directly to schematic.

The cube root step operation was done in forth but not in silicon
because it was the slowest opcode and not thought important enough.

John_H wrote:
I've been playing around with the algorith in my down time. I haven't
put together verilog but the Excel spreadsheet shows everything flows.

I have the square root implemented with the input load/shift register,
a single registered adder and the result shift register. One result
bit per clock.

I have the cube root implemented with the input shift register, two
adders, two registered adders, and the result shift register. One
result bit per clock. No multiplies!

To get verilog together, one would have to specify the number of input
bits and the number of result bits. To illustrate the square root
could be 4 bits input with results to many decimal points, e.g.
(sqrt(4'h2))<<8==10'h16a for a fixed-decimal result of 8 bits,
approximately 1.41406. A fixed-decimal input could also be used as
long as there are 3n decimal bits; shift 3n left for the input, shift
n right for the result.

As long as this isn't homework, I can provide an excel spreadsheet
with the adders broken out or put together verilog based on in/out
port sizes. A generic verilog module could be parameterized but I
don't care to do that right now - getting the register sizes "just
right" for all cases isn't trivial.

Fun!
- John_H

John_H wrote:
A quick google search on "cube root algorithm" brought me to:
http://mathforum.org/library/drmath/view/52605.html
If you've implemented the square root in logic, you'd know how easy
it is to do things in binary. The task now would be to push the new
algorithm into binary. If you find yourself stuck after several hours
of working on it, let me know and I'll diddle with it; these kinds of
algorithms ar fun for me.

john.deepu@gmail.com> wrote:
Hi ,
Can anyone give me some clues regarding how to implement cuberoot
function in RTL for synthesis.

thanks
 
You have carry, propagate, and generate in a CLA.

If you have 2 CLAs, the "overall" propagate would be if both CLAs have a
propagate: carry in means carry out. That's what the propagate is.

If your upper CLA is generate, the overall CLA is generate.
If the lower CLA is generate and the upper CLA is propagate, the overall CLA
is generate.

It's pretty simple if you can understand what the propagate and generate are
intended for. If you have an 8-bit CLA with an intermediate result of
9'hff, the carry output is the carry input. If the intermediate result is
9'h1xx, the carry out wilb be there regardless. If the intermediate result
is less than 9'hff, no carry in can produce a carry out.


"amit" <amit.kohan@gmail.com> wrote in message
news:1116993537.233205.273320@o13g2000cwo.googlegroups.com...
Hi group,

I have a carry look ahead (4-bit) module which I need to instantiate a
8-bit CLA and 16 CLA based on it (dataflow model). I have read a book
about it but I'm totally confused. Can somebody let me know how to do
that ? How can I instantiate a 16 bit CLA module based on a 4-bit.

It will be appreciated.


Code is:


module cla_4b (sum, cout, a, b, cin);

output [3:0] sum;
output cout;

input [3:0] a, b;
input cin;

wire p0, g0, p1, g1, p2, g2, p3, g3;
wire c1, c2, c3, c4;

assign p0 = a[0] ^ b[0], p1=a[1] ^ b[1], p2=a[2] ^ b[2], p3=a[3] ^
b[3];

assign g0=a[0] & b[0], g1=a[1] & b[1], g2=a[2] & b[2], g3=a[3] & b[3];

assign c1 =
g0 | (p0 & cin), c2 = g1 | (p1 & g0) | (p1 & p0 & cin),
c3 = g2 | (p2 & g1) | (p2 & p1 & g0) | (p2 & p1 & p0 & cin),
c4 = g3 | (p3 & g2) | (p3 & p2 & g1) | (p3 & p2 & p1 & g0) | (p3 & p2
& p1 & p0 & cin);

assign sum[0] = p0 ^ cin, sum[1] = p1 ^ c1, sum[2] = p2 ^ c2, sum[3] =
p3 ^ c3;

assign cout = c4;

endmodule
 
plodger@gmail.com wrote:

Hi all,

My PhD research involves analysis and transformation of gate-level
netlists. I'm interested in verification mainly, but also in performing
bla bla bla

evaluation and SAT solvers together in order to do even fancier things.
I'd like to be able to grab a few public domain IP cores, get them into
a format my code can work with, and have some fun with them.

Thanks all,
Sarah Thompson
Here are two excellent FREE Verilog simulators ...

http://icarus.com/eda/verilog/
http://www.pragmatic-c.com/gpl-cver/

rudi
=============================================================
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
 
Generally speaking, there aren't 2-clock flops. But there is such a thing.
A notable example is - I believe - the Xilinx FPGA I/O block DDR output
registers. As I understand it, these are true dual-clock registers, not the
typical dual-registers followed by a select MUX. They can be made, it's
just that there's almost never a use for them.


"Berty" <wooster.berty@gmail.com> wrote in message
news:1117059731.255756.191970@g43g2000cwa.googlegroups.com...
Generally speaking there is no such thing as FF with two clock's.
You might have library that do something but it simple mean that
someone "play around" to somehow combine the two input to generate
one clock or use two FF and so on.

In the most generic way a FF can have one input of clock two input of
async reset and set and two input of sync set and reset, and maybe
clock enable which is basically a muxing back the output when the clock
is not enable.

By writing something which require two clock whether the synthesis will
manage to make something or not you take a huge risk that what you will
get is not what you want and it would be better to design it so you
have only one clock per FF and there is no "who knows what will
happen" scenario.

Have fun.
 
It was notable because it was a two-clock register.
Like a two-sided master/slave latch beast with one output.

Berty wrote:
I'm not sure what Xilinx have in there DDR Output however I have a
strong feeling that even if it look to the user as one part with two
edge it is build from the 2 FF and mux like the "old way" (with
maybe extra latch).

Putting aside the FF base on two latch's one after the other and hence
you might say there is two edge possibility and taking only about the
general FF how do you build one FF with two clock edge ? From physical
point of view there is only one gate/clock.

Or maybe this is what you mean when you wrote notable that for the user
it look like two edge though inside it is build from two FF's (and
maybe a bit more) ?

Have fun.
 

Welcome to EDABoard.com

Sponsor

Back
Top