[Oberon] Fast version of Oberon RISC5 for Pepino

[Magnus Karlsson]

I'm not sure I agree on all of this. In general, if you write some code 
that's logically correct and it meets timing when you run it through 
"compilation" (or whatever you want to call it), then you really don't 
have to care about how it was implemented.

The main difference between software and hardware for the trade off when 
you write more abstract high level code vs. low level code is that in 
software you might loose control of the performance of the code (you 
tend to write assembly code for performance critical sections) while in 
hardware the performance is dictated by the code itself and will not 
change but you might loose control of the resources used for the 
implementation.  In this case, the low-level code that Prof Wirth wrote 
for the multiply module uses 4 hardware multipliers, while my code uses 
8 hardware multipliers, 4 for the unsigned and 4 for the signed.

As for porting, the products offered by the two big players in the FPGA 
market (Xilinx and Altera) typically have similar features (like block 
RAM, hw mulitpliers, PLL units etc.), and porting high level Verilog 
code is typically a low effort task.  The problem is generally sections 
that uses low level instantiation of vendor-specific functions (like 
PLL's,  block RAMs etc.), and the more you use high-level code to 
describe the logic the simpler the porting will be.  For instance, the 
PROM module in the Oberon code is describing the PROM in a high-level, 
vendor neutral way that will port to any FPGA that offers block RAM.  
The one exception to this is if one vendor does not support the latest 
"flavor" of Verilog or VHDL, then the porting will be a much bigger task 
if the code uses construct not available or supported in one vendors 
tools.  An example of this is the Verilog version of the Parallex 
Propeller-1 processor.  It was written for Altera using SystemVerilog 
which is not supported by Xilinx ISE (it only supports up to 
Verilog2001) so the port that I wrote of this code to Xilinx Spartan-6 
was a bit of an undertaking even though it's written in high-level Verilog.

https://www.parallax.com/microcontrollers/propeller-1-open-source
http://forums.parallax.com/discussion/157004/propeller-1-running-on-pipistrello-xilinx-spartan6-lx45

Magnus

On 3/1/2016 7:05 AM, skulski at pas.rochester.edu wrote:
> ________________________________________
> From: Chris Burrows [chris at cfbsoftware.com]
> There are two versions of Multiplier still available on Prof Wirth's site.
> One which is portable (Multiplier.v) and one which uses the fast 18 x 18 bit
> multiplier units (Multiplier1.v):
>
> Chris:
>
> Spartan-3 was the first generation that provided the silicon implementing
> 18x18 multipliers. Since NW code was written for Spartan-3, it is not
> surprising that he provided the targeted version of the code.
>
> Subsequent generations added more silicon features inside these blocks,
> such as multiply-accumulate registers. The blocks were renamed "DSP
> slices". More features are being added to these in every new generation.
>
> Writing Verilog/VHDL code that is portable among these generations may be
> tricky. One can adopt Magnus' approach by writing high level code
> expressing the intent, and then let the compiler "infer" the proper
> circuit. (FPGA compilers do not compile, they "infer" according to the
> official slang.) The word "infer" means that the designer should check in
> the compilation report whether or not the compiler guessed right, and
> change the syntax if not.
>
> My general conclusion is that the FPGA code only pretends to be portable.
> Yes, you can write code which looks obvious. No, you cannot assume that
> the obvious code is translated according to the intent. You need to check
> whether this particular compiler "inferred" the proper circuit for this
> particular FPGA.
>
> I am also skeptical about writing code in LOLA, translating to Verilog,
> and claiming it is the end of the problem. In my mind LOLA is a sketch of
> the final solution rather than the final solution which needs to be
> written in the way the vendor recommends. It means VHDL/Verilog.
>
> I also think that having slightly different variants of the code for
> various FPGA families cannot be avoided.
>
> Just my experience. Yours may differ.
>
> Wojtek
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>