[Oberon] FPGA - Colour Support

[Skulski, Wojciech]

Joerg:

  your diagram is entirely fine. However, you canot run any Q, Q#, AND (Q,Q#), or anything like this into the CLK inputs of the other flip-flops. I mean, the inputs marked with triangles.

The intent of the code snippet which you posted was to generate clocking signals of half the frequency, which are then routed to some flip flops in the design. This is not allowed because there is no direct connection from the flip-flop outputs, or from the AND gate output, to any of the flip-flop clocking inputs anywhere. These triangle inputs are on an entirely separate "clocking tree". 

You may use the derived clock by connecting it to the clocking tree. This should be done explicitly like the following. The "derived_clock" is routed via the BUFG, which physically is a very strong current driver, to the "clocking tree" connected to the output "O". As far as I know, Xilinx does not recommend this practice. They rather recommend using "clock enable" inputs of the flip-flops. These inputs were not shown in your diagram.

Note that the connection via the BUFG can be inserted by the Xilinx tools themselves, without you being aware. If this happens then you will be notified in the translation reports. Not looking into these, you may stay under the impression that the clock derivation is a simple thing to write in the code. You may not be aware that your design is consuming these BUFG drivers to achieve the goal. 

-- global clock buffer for signal processing
clk100_buf: BUFG
 port map(
I  => derived_clock,
O => system_clock
);

W.
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Saturday, October 7, 2017 3:12 PM
To: ETH Oberon and related systems
Subject: Re: [Oberon] FPGA - Colour Support

Hi Wojtek



Are you saying FPGA can not implement this:?



[cid:image001.png at 01D33FB0.F72AFD20]



Am 07.10.17, 20:26 schrieb "Oberon im Auftrag von Skulski, Wojciech" <oberon-bounces at lists.inf.ethz.ch im Auftrag von skulski at pas.rochester.edu>:



    Joerg:



    These clock manipulations look interesting. I wonder how ISE or Vivado translate these into logic. Combinatorial clocks cannot be used in FPGA designs. Combinatorial means "derived from logic equations" like the ones we see below. The reason is that the clocking inputs to flip flops are seldom (if ever) directly connected to the fabric, where such equations are implemented in hardware. And even if such connections exist (I doubt they do), using them is strongly discouraged by the FPGA manufacturers. Maybe ISE tools are smart enough to somehow pack these equations into the Digital Clock Manager (DCM)?



    So it is an interesting piece of HDL which is calling either for a rework or for examination of the translation report to find out, how it is implemented by the tools. If you want to divide the clock by five, then I am pretty sure the DCM will need to be used.



    Concerning the SPI, it can run at a wide range of frequencies. Perhaps some part has some special requirements, which then need to be dealt with locally in the respective HDL module.



    W.

    ________________________________________

    For the OberonStation, RISC5Top.v looks like this:



    always @(posedge clk0) clk <= ~clk;



    always @(posedge clkfx) begin

      clk0 <= ~clk0 & ~clk1; clk1 <= clk0;

      pclk <= ~pclk;

    end





    clkfx runs at 150 MHz

    pcclk runs at 75 MHz (VGA timing)

    clk0 runs at 50 MHz

    clk runs at 25 MHz



    So, instead of dividing by 3 and then by 2 to get to clk, we would need to divide clkfx by 5.

    Of course the SPI divider „tick“ needs to adopted from 63 to 75 and so on. (400 kHz = 25MHz / 63 = 30 MHz / 75)

    Sorry, I forgot to mention these details.



    --

    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems

    https://lists.inf.ethz.ch/mailman/listinfo/oberon



-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14241 bytes
Desc: image001.png
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171007/13552894/attachment.png>