[Oberon] RISC5 implementation issues.

[Walter Gallegos]

Hola Pablo

I use VHDL also, is safer. opp... keep calm I'm not trying to start the 
war again.

I'm working in a VHDL version of RISC5 but as free time project; if you 
have some free time you are welcome ( walter at waltergallegos.com)

Saludos,
Walter

PD : I like wine.

El 2016-02-16 a las 15:14, Pablo Cayuela escribió:
> As a professor I teach Programmable Logic at Universidad Tecnologica 
> Nacional, Cordoba, Argentina, encouraging Synchronous Design for FGPAs.
> It is really useful your suggestions for corrections to the design of 
> RISC5. I wonder if you or someone else have a VHDL version of RISC5, 
> because we use VHDL in classes and it could be useful to use it as an 
> application example. It could be useful a recipe version of your 
> suggestion for reimplementing RISC5 in the Verilog version.
> I'm always been considering Wirth's LoLa as a tool but I could not use 
> it in classes right now. And for Verilog, it was not chosen for the 
> Digital Basics Courses and that's why we continue in our course with 
> VHDL, that we consider more convenient for teaching.
>
> Sincerely yours,
>
> Pablo Cayuela
>
>
> On Tue, Feb 16, 2016 at 2:22 PM, Walter Gallegos 
> <walter at waltergallegos.com <mailto:walter at waltergallegos.com>> wrote:
>
>     I've waited long time before post this topic because could be
>     misunderstood, believe me this is a positive post. Try to address
>     a methodology  issue in RISC 5 implementation.
>
>     The gold rule is "FPGA design must be synchronous". Have a clock
>     do not means synchronous.
>
>     Building the hardware from Verilog description.
>
>     DCM_SP #( .CLK_FEEDBACK("NONE"), .CLKDV_DIVIDE(2.0), .CLKFX_DIVIDE(2),
>         .CLKFX_MULTIPLY(5), .CLKIN_DIVIDE_BY_2("FALSE"),
>         .CLKIN_PERIOD(16.667), .CLKOUT_PHASE_SHIFT("NONE"),
>         .DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"), .DFS_FREQUENCY_MODE("LOW"),
>         .DLL_FREQUENCY_MODE("LOW"), .DUTY_CYCLE_CORRECTION("TRUE"),
>         .FACTORY_JF(16'hC080), .PHASE_SHIFT(0), .STARTUP_WAIT("FALSE") )
>       dcm ( .CLKIN(OSCIN), .CLKFX(clkfx), .CLKFB(1'b0), .RST(1'b0),
>         .DSSEN(1'b0), .PSCLK(1'b0), .PSEN(1'b0), .PSINCDEC(1'b0),
>         .CLKDV(), .CLKFX180(), .CLK0(), .CLK2X(), .CLK2X180(),
>         .CLK90(), .CLK180(), .CLK270(), .LOCKED(), .PSDONE(), .STATUS());
>
>     This implement a DCM with OSCIN as input clock to generate clkfx;
>     for DCMs the XILINX recommend some period in reset with CLKIN
>     active and stable. Work yes, recommended no. Is also a good
>     practice rebuild the input clock with the DCM and not only
>     generate a new one.
>
>     always @(posedge clkfx) begin
>       clk0 <= ~clk0 & ~clk1;     This implement a FF feeback = not
>     clk0 and not clk1.
>       clk1 <= clk0;                       clk1 is also another FF
>     taking clk0 as data.
>       pclk <= ~pclk;                     pclk is a FF feedback Q in D
>     end
>
>     Please note, clk0, clk1 and pclk are not aligned, they are
>     different FF with different placement and routing.
>     If used as clock, this one of the worst cases, edges are closed,
>     not the same, routed into uncontrolled skew general propose
>     routing resources, don't forget of metastability.
>
>     Next,
>
>     always @(posedge clk0) clk <= ~clk;
>
>     "posedge" force the implementation tool to use the clock edge
>     detection available in each FPGA FF; so, this sentence force the
>     tool to connect a general purpose interconnection network as FF
>     output is to the clock distribution tree.
>
>     And again a signal ( not a clock in the FPGA world ) is used as clock.
>
>     always @(posedge clk)
>     ....
>     end
>
>     There are also another hidden problem, the RISC clock clk, that
>     was generated in the logic farm, is not aligned with clkfx by a
>     variable unknown delay. This delay depend of several factor as
>     temperature, power supply voltage and implementation run, that
>     means in two implementation runs of same code as the tool could
>     select different placement and routing  could result in different
>     delays.
>
>     The correct way to handle clock is with a clock manager; I strong
>     recommend avoid clock dividers in logic. The challenge is select a
>     correct oscillator and/or the appropriate multiply divide parameters.
>
>     And after correct this problems don't forget to modify :
>
>     assign SRwe0 = ~wr | clk, SRwe1 = SRwe0;
>
>     Here clk is used as signal, so if clk is a clock must not be
>     connected to a LUT input.
>
>     Regards,
>
>     -- 
>
>     Walter Daniel Gallegos
>     Programmable Logic & Software
>     Consultoría, Diseño, Entrenamiento.
>     Montevideo, Uruguay
>     EMAIL walter at waltergallegos.com <mailto:walter at waltergallegos.com>
>     Tel +598 26 23 44 60 | Cel +598 99 18 58 88
>
>     --
>     Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch> mailing
>     list for ETH Oberon and related systems
>     https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon

-- 

Walter Daniel Gallegos
Programmable Logic & Software
Consultoría, Diseño, Entrenamiento.
Montevideo, Uruguay
EMAIL walter at waltergallegos.com
Tel +598 26 23 44 60 | Cel +598 99 18 58 88


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160216/0b719c8e/attachment-0001.html>