[Oberon] RISC5 implementation issues.

[Magnus Karlsson]

On 2/16/2016 12:33 PM, Magnus Karlsson wrote:
> On 2/16/2016 11:37 AM, Walter Gallegos wrote:
>> Magnus
>>
>> "This logic signal /clk/ is then connected to a clock buffer BUFG 
>> that will feed one of the global clock nets"
>>
>> My apologies, clk routing is :
>>
>> The logic clk signal -using general propose routing lines and 
>> connection matrix- is connected to a clock buffer to be able to be 
>> connected to FF edge detectors. This is the only way that the tool 
>> can address the HDL definition.
>>
>> So, RISC5 use general propose resources to routing a clock signal.
>>
>> Walter.
>>
>
> There is absolutely nothing wrong with generating a clock signal like 
> this.
> Yes, the output from the flip-flop is routed using general routing 
> resources, there is no other option.   But after it's sent through the 
> BUFG it's a perfectly legit clock signal.
>
> I have created a small project to demonstrate this, it's available on 
> GitHub and it will only take ISE a few seconds to generated a bit file.
> *ISE will go through this project without a single warning being 
> generated.*  Anyone with ISE experience will tell you that it will 
> generate warning for every little detail it will find questionable.
>
> The project is available here: 
> https://github.com/Saanlima/Pepino/tree/master/Projects/Pepino_clktest
>
> Magnus

This can of course also be done using dedicated clocking resources like 
a DCM or a PLL instead of just a simple flip-flip, and I guess Paul Reed 
is the correct person to defend why it was done like this but I have a 
pretty good hunch why.

The SRAM interface is asynchronous in nature and care must be taken so 
that the timing of the write signal is such that it prevents accidental 
writes to other memory locations during a write cycle. If all the 
signals controlling the SRAM (like address, chip enable, read, write, 
and output enable) are generated synchronously using the CPU clock then 
the timing of the write signal relative to the other control signals are 
uncertain and can vary depending on the routing of the chip.  By gating 
the write signal with the "early" version of the clk signal (i.e. the 
clk version of the signal, not the clk_BUFG version) which is guaranteed 
to lead the clk_BUFG signal by the delay caused by the buffer, then the 
write signal to the memory is guaranteed to be removed before the other 
signals can change.  If the clk signal is generated by a DCM or a PLL 
then this early version of the clk signal is not available like Walter 
pointed out and the write timing must be controlled by some other 
mechanism, like a state machine clocked at say 2x or 4x the CPU clock.

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