[Oberon] RISC5 implementation issues.

[Pablo Cayuela]

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>
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
> Tel +598 26 23 44 60 | Cel +598 99 18 58 88
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160216/c8ef3b8a/attachment.html>