OpenSPARC released

"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.

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

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

Austin Lesea wrote:
> I wonder if there is any reason why it would be useful to compile the
> verilog for a FPGA?

I don't understand...
What You mean?
 - Verilog is the problem (VHDL is better) or
 - "openSparc Verilog" is the problem (better other "soft-cpu") ?

Sandro

On 27 Mar 2006 06:14:16 -0800, "Sandro" <sdroamt@netscape.net> wrote:

>Austin Lesea wrote:
>> I wonder if there is any reason why it would be useful to compile the
>> verilog for a FPGA?
>
>I don't understand...
>What You mean?
> - Verilog is the problem (VHDL is better) or
> - "openSparc Verilog" is the problem (better other "soft-cpu") ?

It appears openSparc Verilog is written to target an ASIC, not an
FPGA.  Whilst it might be possible to get it to compile and even fit
into an FPGA, the performance would probably not be stunning.

In that sense, a different soft-cpu designed to be used on an FPGA
would probably be better.

Regards,
Allan

Allan Herriman wrote:

> It appears openSparc Verilog is written to target an ASIC, not an
> FPGA.  Whilst it might be possible to get it to compile and even fit
> into an FPGA, the performance would probably not be stunning.
>
> In that sense, a different soft-cpu designed to be used on an FPGA
> would probably be better.

---It's interesting to see "SoftCores for Multicore FPGA
implementations" listed as an example research area that can be
explored with OpenSPARC technology, at
http://opensparc.sunsource.net/nonav/research.html. Not sure what
area/delay/power one would end up with if this core is implemented on
an FPGA as is. Perhaps certain enhancements/simplifications may be
carried out to the present core in order to make it useful within an
FPGA. Since they have released a variety of hardware/software tools
(and their sources) I guess it becomes possible to study the
performance impact of any architectural modifications.

Has anybody already started working on implementing this on an FPGA? I
would be very interested to know the results.I want to try to do this
but am presently hampered because I don't have Synopsys DC (which is
the recommended synthesis environment) appropriately set up.

Thanks,
Shyam