Re: [oc] To Jason

[Joachim Strömbergson<Joachim.Strombergson@InformAsic.com>]

Aloha!

jae lim wrote:
> Hello Jason 
> 
> Thank you very much for your input!
 >
>A better approach might be to design the pipeline
>>with various points at which the execution could be
>>registered and turn them on or off using synthesis 
>>directives and GENERICS.Thus for different FPGA 
>>architectures and synthesis tools the code could be 
>>optimized to have the best performance.
> 
> How can I design the pipeline at different points at
> which the execution could be registered? What is
> GENERICS?

There are different ways to do this. Both Verilog and VHDL have constructs 
built into the language that lets you apply parameters/control values/generics 
and have the RTL-tools parse the parameters and adjust the RTL during parsing 
to the final RTL used by the tool.

If you have experience with C programming, you can view this as something like 
pragmas and preprocessor directives. (Both Verilog and VHDL have pragmas too, 
but that's not what we are talking about here)

Depending on which language you are using you should read up on the different 
constructs for that specific language.

Another approach is to divide your design into an architecture with blocks 
that can be instansiated and then have use a script to generate the RTL for 
you. What you do is basically the following. Assuming that all Fs are purely 
combinational functional blocks (ie logic) and vertical lines are clock lines 
(i.e registers) you get a standard Werner diagram like this:

|    |    |    |    |    |
| F1 | F2 | F3 | F4 | F5 |
|    |    |    |    |    |

A Perl script having access to the RTL for F1 - F5 and a parameter with number 
of stages needed can generate a top level with the registers and connect the 
blocks to the registers. The same pipeline can thus be generated with anything 
from 1 to 5 stages suitable for slow speed to high speed operation.

The generics basically do the same thing so you may choose whichever solution 
that you feel suits your way of designing. We have adopted the scripting 
approch not only because it suits our methodology approach, but also because 
we have previous experience with EDA tools having different ways of 
using/interpreting generics.

If your synthesis tool generates a different design internally compared to 
your simulator, coverage tool, power estimator and/or floor planner, you will 
have days of fun. ;-)


> And also, about the control logic, could you explain
> to me in more detail? I am really new to this area:--(

Consider the pipeline above, If you would have a central control machine that 
looks at the result from F1 and will send a control message to F5 when the 
result reaches F5, the control machine would have to be able to wait anywhere 
from 1 to 4 steps (clock cycles) before sending the message. This is naturally 
due to the number of stages.

This can be solved in different ways. Stage local control machines 
communicating only with it's neighbours, pipelined message queues etc.

It's really not that hard, think that you shrink or stretch the pipeline and 
then consider what happens to the pipeline internally as well as surrounding 
data and control paths.

Good luck!

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
VP, Research & Development
----------------------------------------------------------------------
InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden
Tel: +46 31 68 54 90  Fax: +46 31 68 54 91  Mobile: +46 733 75 97 02
E-mail: joachim.strombergson@informasic.com  Home: www.informasic.com


--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml