[Oberon] RISC5 implementation issues.

[Magnus Karlsson]

Walter, be careful here.  The code you list is specific to 
OberonStation, it does not look like this on the original Digilent 
Spartan3 board nor on Pepino.
This is the (somewhat messy) way OberonStation creates the 25 MHz CPU 
clock and the 75 MHz pixel clock for a 60 MHz input clock.

Both the Digilent board and Pepino uses a 50 MHz input clock and the 
clock generation code is much simpler and looks like this:

25 MHz CPU clock (clk) is created by dividing the input clock by 2:
/always @ (posedge CLK50M) clk <= ~clk;/

75 MHz Pixel clock (pclk) is generated by multiplying the CPU clock by 3 
using a DCM:
/DCM #(.CLKFX_MULTIPLY(3), .CLK_FEEDBACK("NONE"), .CLKIN_PERIOD(40.000))//
//  dcm(.CLKIN(clk), .CLKFB(1'b0), .RST(1'b0), .PSEN(1'b0),//
//      .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk));/


Magnus



On 2/16/2016 9:22 AM, Walter Gallegos 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,
>

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