need a cheap student edition FPGA

I found this in design/sys/iop/sparc/ifu/rtl/sparc_ifu_rndrob.v

....
assign next_pv[0] = pv[0] | reset;

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());

....

I don't see how the #4 is legal is Verilog 2001.
Can someone explain to me under what it means,
and under what circumstances this is legal?
Is this construct part of Verilog 2001, or is it vendor specific?

-- IDB
 
"Pablo Bleyer Kocik" <pablobleyer@hotmail.com> wrote in message
news:1143352457.542187.192280@e56g2000cwe.googlegroups.com...
Plain ol' verilog udp?
dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());

....

I don't see how the #4 is legal is Verilog 2001.


The Verilog standard says:

A.5.4

udp_instantiation = udp_identifier [ drive_strength ] [delay2] udp_instance
{ , udp_instance } ;
udp_instance = [name_of_udp_instance] ( output_terminal , ....

A.3.3:

output_terminal = net_lvalue

I can't see how from the Verilog grammar that the sequence
.din
is allowed as net_lvalue.

So, this must be a module instantiation, which doesn't allow the #4.

Am I missing something obvious?

A deriivation of output_terminal to the concrete terminals .din would be
appreciated.

-- IDB
 
On Sat, 25 Mar 2006 22:59:57 -0600, "Ira Baxter"
<idbaxter@semdesigns.com> wrote:

I found this in design/sys/iop/sparc/ifu/rtl/sparc_ifu_rndrob.v

....
assign next_pv[0] = pv[0] | reset;

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());

....

I don't see how the #4 is legal is Verilog 2001.
Can someone explain to me under what it means,
and under what circumstances this is legal?
Is this construct part of Verilog 2001, or is it vendor specific?
Looks like a parameter override. The standard specifies paranthesis
around the number but I bet if only one number is used most tools
accept one without a number. Is there parameter for the module "dff"?
 
On Sun, 26 Mar 2006 10:09:52 GMT, mk<kal*@dspia.*comdelete> wrote:

On Sat, 25 Mar 2006 22:59:57 -0600, "Ira Baxter"
idbaxter@semdesigns.com> wrote:

I found this in design/sys/iop/sparc/ifu/rtl/sparc_ifu_rndrob.v

....
assign next_pv[0] = pv[0] | reset;

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());

....

I don't see how the #4 is legal is Verilog 2001.
Can someone explain to me under what it means,
and under what circumstances this is legal?
Is this construct part of Verilog 2001, or is it vendor specific?

Looks like a parameter override. The standard specifies paranthesis
around the number but I bet if only one number is used most tools
accept one without a number. Is there parameter for the module "dff"?
No, the #4 matches the syntax of a delay specification. Parameter
overrides alway have the ().

Delays specifications are legal between the "module" id and the
instance name in an instantiation of a gate primitive or UDP, but not
in a module instantiation.

dff isn't a gate primitive, so it must be a UDP. However, it seems
that the standard only allows ordered parameter assignments and not
named parameter assigments for UDPs.


Therefore the code isn't legal according to the standard.

This seems to be a mistake in the standard. Does anyone know why it
doesn't allow named parameter assignments for UDPs?


Regards,
Allan
 
You're right. In some designs there is a weak correlation between
Verilog line count and gate count. But unless you take that to an
extreme, this is still quite a large design.
 
This "Behavioral style" is an attempt to optimize for faster
simulation. In reality, it may end up running a lot slower, depending
on your simulator.
 
On Sun, 26 Mar 2006 22:47:13 +1000, Allan Herriman
<allanherriman@hotmail.com> wrote:

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());
....
dff isn't a gate primitive, so it must be a UDP. However, it seems
that the standard only allows ordered parameter assignments and not
named parameter assigments for UDPs.


Therefore the code isn't legal according to the standard.

This seems to be a mistake in the standard. Does anyone know why it
doesn't allow named parameter assignments for UDPs?
I must be missing something. Why is a named parameter assignment
needed ? Isn't this an ordered parameter assignment ?
 
On Mon, 27 Mar 2006 01:12:41 GMT, mk <kal*@dspia.*comdelete> wrote:

On Sun, 26 Mar 2006 22:47:13 +1000, Allan Herriman
allanherriman@hotmail.com> wrote:

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());
...
dff isn't a gate primitive, so it must be a UDP. However, it seems
that the standard only allows ordered parameter assignments and not
named parameter assigments for UDPs.


Therefore the code isn't legal according to the standard.

This seems to be a mistake in the standard. Does anyone know why it
doesn't allow named parameter assignments for UDPs?

I must be missing something. Why is a named parameter assignment
needed ? Isn't this an ordered parameter assignment ?
In the above code,

(
..din(next_pv),
..clk(clk),
..q(park_vec),
..se(se),
..si(),
..so()
)

is a named parameter assignment.


An ordered parameter assignment would look more like

(
next_pv,
clk,
park_vec,
se
)


Regards,
Allan
 
On Mon, 27 Mar 2006 12:56:10 +1000, Allan Herriman
<allanherriman@hotmail.com> wrote:

On Mon, 27 Mar 2006 01:12:41 GMT, mk <kal*@dspia.*comdelete> wrote:

On Sun, 26 Mar 2006 22:47:13 +1000, Allan Herriman
allanherriman@hotmail.com> wrote:

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());
...
dff isn't a gate primitive, so it must be a UDP. However, it seems
that the standard only allows ordered parameter assignments and not
named parameter assigments for UDPs.


Therefore the code isn't legal according to the standard.

This seems to be a mistake in the standard. Does anyone know why it
doesn't allow named parameter assignments for UDPs?

I must be missing something. Why is a named parameter assignment
needed ? Isn't this an ordered parameter assignment ?

In the above code,

(
.din(next_pv),
.clk(clk),
.q(park_vec),
.se(se),
.si(),
.so()
)

is a named parameter assignment.
Oh, you mean "named port connection" in which case you're correct. The
port assignment of UDPs can only be done by order. "named parameter
assignment" is something entirely different.
 
On Mon, 27 Mar 2006 03:40:36 GMT, mk <kal*@dspia.*comdelete> wrote:

On Mon, 27 Mar 2006 12:56:10 +1000, Allan Herriman
allanherriman@hotmail.com> wrote:

On Mon, 27 Mar 2006 01:12:41 GMT, mk <kal*@dspia.*comdelete> wrote:

On Sun, 26 Mar 2006 22:47:13 +1000, Allan Herriman
allanherriman@hotmail.com> wrote:

dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());
...
dff isn't a gate primitive, so it must be a UDP. However, it seems
that the standard only allows ordered parameter assignments and not
named parameter assigments for UDPs.


Therefore the code isn't legal according to the standard.

This seems to be a mistake in the standard. Does anyone know why it
doesn't allow named parameter assignments for UDPs?

I must be missing something. Why is a named parameter assignment
needed ? Isn't this an ordered parameter assignment ?

In the above code,

(
.din(next_pv),
.clk(clk),
.q(park_vec),
.se(se),
.si(),
.so()
)

is a named parameter assignment.

Oh, you mean "named port connection" in which case you're correct. The
port assignment of UDPs can only be done by order. "named parameter
assignment" is something entirely different.
Uh, yes, you're right. Sorry, I copied the wrong bit out of the
standard and confused myself.

Still, I don't understand why named port connection isn't allowed for
a UDP.

Regards,
Allan
 
Austin Lesea wrote:

Chris,

Brings up a question for the group: how many lines of verilog can you
fit in any given FPGA?

Anyone out there in the ASIC emulation world care to comment?
There is no answer for that, it is very dependent on the designs and
the application field. Processors and telecom chips have quite different
needs for the FPGA for example.

In the telecom side usually there is enough DFFs and logic resources. And the
FPGA size can be determined with the help of internal ram resources.

--Kim
 
This job could be done by youself...

function your_expression(in, num);
input [MAX_IN_LEN:0] in;
input [31:0] num; // 2^32-1 should be enough. Add more if required
reg res;
integer i;
begin
res=0;
for(i=0;i<num;i=i+1) begin
res = res | (&in[i:0]);
end
your_expression = res;
end
endfunction
 
Austin Lesea wrote:

Chris,

Brings up a question for the group: how many lines of verilog can you
fit in any given FPGA?

Anyone out there in the ASIC emulation world care to comment?
There is no answer for that, it is very dependent on the designs and
the application field. Processors and telecom chips have quite different
needs for the FPGA for example.

In the telecom side usually there is enough DFFs and logic resources. And the
FPGA size can be determined with the help of internal ram resources.

--Kim
 
This job could be done by youself...

function your_expression(in, num);
input [MAX_IN_LEN:0] in;
input [31:0] num; // 2^32-1 should be enough. Add more if required
reg res;
integer i;
begin
res=0;
for(i=0;i<num;i=i+1) begin
res = res | (&in[i:0]);
end
your_expression = res;
end
endfunction
 
You also aren't going to get an accurate FPGA gate count after ASIC
synthesis.
If I synthesized this OpenSparc processor with DC, targetted a certain
ASIC cell library and got a count of 1 million gates for instance, that
might be resynthesized for a Virtex2 part and be 2 million gates.
Just as an example, I have no clue about these numbers except FPGA
gates will be more.
 
Jan Decaluwe wrote:

As for the SPARC code, it seems like an extreme example. I wouldn't
call this RTL code. It's more like a manually generated technology-
independent netlist. For example, they don't even use flip-flop
inference. And they do have excessive hierarchy.

I suspect that it should be possible to gain at least an order
of magnitude in terms of lines of code by using a proper RTL
style. And the synthesis results might be better. (Excessive
hierarchy tends to yield suboptimal synthesis results).


That's what I was afraid of. Structural netlists are useful for transmitting
an intact design without revealling the "real source" code. That code is what
you need if you really want to understand or modify the design.

This is like compiling a C file into a linked assembler file and releasing
that as "open source". You can create an executable but that's about it.

Thanks but no thanks.


John Eaton
 
J o h n _ E a t o n (at) hp . com (no spaces) wrote:
Why not? This would be a great teaching tool for fpga design and/or
computer system design courses at college level.

Only if it can fit into an FPGA. Anybody have a gatecount?
Even if it didn't - having source to a modern commercial processor would
still be useful - I recall someone was asking about this on the group a
little while ago.

Jeremy
 

Welcome to EDABoard.com

Sponsor

Back
Top