[Oberon] RISC5 implementation issues.
Walter Gallegos
walter at waltergallegos.com
Tue Feb 16 23:37:17 CET 2016
repost
El 2016-02-16 a las 18:27, Walter Gallegos escribió:
> Magnus,
>
> The correct technique to solve this is use a DCM with 50MHZ connected
> to CLKIN, connect clk to CLKDIV and pclk to CLKFX. Setting the divider
> to 2 and M/D to 3/2. Is the same DCM used to generate the pixel clock,
> so have no sense use a "bad practice" solution when the correct is
> used in the project.
>
> Regards,
> Walter
>
> El 2016-02-16 a las 16:52, Walter Gallegos escribió:
>> Magnus,
>>
>> /always @ (posedge CLK50M) clk <= ~clk;
>>
>> /This is also a bad practice. clk edge are not aligned with CLK50M
>> in a uncontrolled fashion. So, this is a kind of asynchronism for the
>> rest of FPGA.
>>
>> Walter
>>
>>
>> El 2016-02-16 a las 15:14, Magnus Karlsson escribió:
>>> 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,
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>> EMAILwalter 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
>
> --
>
> Walter Daniel Gallegos
> Programmable Logic & Software
> Consultoría, Diseño, Entrenamiento.
> Montevideo, Uruguay
> EMAILwalter at waltergallegos.com
> Tel +598 26 23 44 60 | Cel +598 99 18 58 88
>
>
> El presente correo y cualquier posible archivo adjunto está dirigido únicamente
> al destinatario del mensaje y contiene información que puede ser confidencial.
> Si Ud. no es el destinatario correcto por favor notifique al remitente
> respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los
> posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier
> utilización, difusión o copia de este e-mail por cualquier persona o entidad
> que no sean las específicas destinatarias del mensaje.
>
> This e-mail and any attachment is confidential and is intended solely for the
> addressee(s). If you are not intended recipient please inform the sender
> immediately, answering this e-mail and delete it as well as the attached files.
> Any use, circulation or copy of this e-mail by any person or entity that is not
> the specific addressee(s) is prohibited.
>
--
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
El presente correo y cualquier posible archivo adjunto está dirigido únicamente
al destinatario del mensaje y contiene información que puede ser confidencial.
Si Ud. no es el destinatario correcto por favor notifique al remitente
respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los
posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier
utilización, difusión o copia de este e-mail por cualquier persona o entidad
que no sean las específicas destinatarias del mensaje.
This e-mail and any attachment is confidential and is intended solely for the
addressee(s). If you are not intended recipient please inform the sender
immediately, answering this e-mail and delete it as well as the attached files.
Any use, circulation or copy of this e-mail by any person or entity that is not
the specific addressee(s) is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20160216/31d50a73/attachment-0001.html>
More information about the Oberon
mailing list