<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Courier New, Courier, monospace"><br>
DCM #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"),
.CLKIN_PERIOD(20.000))<br>
dcm(.<b>CLKIN(CLK50M)</b>, .CLKFB(clk), .RST(1'b0), .PSEN(1'b0),<br>
.PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk), .<b>CLK0(clk)</b>,<br>
.CLK90(clk90));</font><br>
<br>
clk = CLK0 = CLKIN = CLK50M. Can this version of RISC5 run at 50MHZ
as is ?<br>
<br>
Here my simulation using de Cypress SRAM VHDL simulation model with
ALDEC simulator.<br>
<br>
Label : "Potential Issue", If you read the SRAM and - in the next
clk cycle - try to write the same SRAM data bus we could wait some
ns of bus contention at this point.<br>
If RISC5 can read then write in consecutive clk cycles the issue is
easy worked capturing de SRAM data with 90° clock rising_edge and
releasing oen soon. <br>
Important note : This functional simple test bench do not take in
count internal RISC5 timing issues.<br>
<br>
Question to RISC5 fathers and adopters : Someone build an "official"
test bench set for RISC5 ? That means module by module plus one
total. <br>
Is the test bench available ? <br>
<br>
<img src="cid:part1.05000800.02070909@waltergallegos.com" alt=""><br>
<br>
I'm more interested in practical uses; as an -industrial grade-
embedded RISC5; how many in this list, <span id="result_box"
class="short_text" lang="en"><span class="hps">in addition to
those</span> <span class="hps">we</span> <span class="hps">already
know,</span></span> walk in the same direction ? <br>
<br>
Best regards<br>
Walter<br>
<br>
<br>
<div class="moz-cite-prefix">El 2016-02-23 a las 13:49, Magnus
Karlsson escribió:<br>
</div>
<blockquote cite="mid:56CC8D81.90804@saanlima.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Walter,<br>
<br>
I tried your proposed solution and couldn't make it work. It
"almost" works in that it starts the boot process and reads from
the SD-card, but then hangs with the LEDs showing 0x84.<br>
Maybe I didn't do it correct, I instantiated the ODDR2 buffer
directly at the top module and modified the DCM instantiation to
create the clk90 clock.<br>
<br>
Here is the code, can you look it over and see if this is what
you had in mind or if something is wrong:<br>
<br>
<font face="Courier New, Courier, monospace">DCM
#(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"),
.CLKIN_PERIOD(20.000))<br>
dcm(.CLKIN(CLK50M), .CLKFB(clk), .RST(1'b0), .PSEN(1'b0),<br>
.PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0),
.CLKFX(pclk), .CLK0(clk),<br>
.CLK90(clk90));<br>
<br>
ODDR2 #(.INIT(1'b1))<br>
oddr2(.Q(wr_enable), .C0(clk90), .C1(~clk90), .CE(1'b1),
.D0(1'b1),<br>
.D1(~wr), .R(1'b0), .S(1'b0));</font><br>
<br>
<font face="Courier New, Courier, monospace">assign SRwe =
wr_enable;<br>
<br>
</font><br>
wr is the active-high write signal from the RISC5 CPU, and SRwe
is the short active-low write-enable signal to the SRAM.<br>
<br>
Just to recap, this is the code I used to generate the short
write pulse, using a 2x clk instead. This version seems to run
fine:<br>
<br>
<font face="Courier New, Courier, monospace">reg wr_enable;</font><br>
<br>
<font face="Courier New, Courier, monospace">DCM
#(.CLKFX_MULTIPLY(3), .CLKFX_DIVIDE(2), .CLKDV_DIVIDE(2),
.CLKIN_PERIOD(20.000))<br>
dcm(.CLKIN(CLK50M), .CLKFB(clk2x), .RST(1'b0), .PSEN(1'b0),<br>
.PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0),
.CLKFX(pclk), .CLKDV(clk), .CLK0(clk2x));<br>
<br>
always @(negedge clk2x)<br>
wr_enable <= wr & ~wr_enable;<br>
<br>
assign SRwe = ~wr_enable;<br>
<br>
</font><br>
Any idea what's wrong?<br>
Magnus<br>
<br>
<br>
On 2/19/2016 9:58 AM, Walter Gallegos wrote:<br>
</div>
<blockquote cite="mid:56C757AE.5070807@waltergallegos.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Let us concentrate in the problem...<br>
<br>
How to generate an output pulse shorter than clock period?<br>
<br>
You can make a pulse shorter with help of DCM and DDR ( dual
data rate output registers ) see the simulation capture <br>
<br>
<img src="cid:part2.09060302.03020108@waltergallegos.com" alt=""><br>
<br>
clk25f90 is the DCM clock output with 90° phase shift.<br>
<br>
The VHDL code is : ( without DCM instantiation )<br>
<br>
ENTITY PulseShaper IS<br>
PORT (CLK25F90 : IN STD_LOGIC;<br>
RESET : IN STD_LOGIC;<br>
WE : IN STD_LOGIC;<br>
WESRAM : OUT STD_LOGIC<br>
);<br>
END PulseShaper;<br>
<br>
ARCHITECTURE RTL OF PulseShaper IS<br>
<br>
CONSTANT zero : STD_LOGIC := '0';<br>
CONSTANT one : STD_LOGIC := '1';<br>
<br>
SIGNAL clk90n: STD_LOGIC;<br>
<br>
BEGIN<br>
<br>
clk90n <= NOT(CLK25F90); -- This is valid because the
tool use the clock inverter available in IOB<br>
<br>
Dly : ODDR2<br>
PORT MAP (<br>
Q => WESRAM, <br>
C0 => CLK25F90, <br>
C1 => clk90n, <br>
CE => one, <br>
D0 => one, <br>
D1 => WE, <br>
R => zero, <br>
S => zero <br>
);<br>
<br>
END RTL;<br>
<br>
Someone know if exist a FPGA testbench for RISC5 ?<br>
<br>
Regards,<br>
Walter<br>
<br>
<div class="moz-cite-prefix">El 2016-02-19 a las 11:33, Magnus
Karlsson escribió:<br>
</div>
<blockquote cite="mid:56C727AF.5020201@saanlima.com" type="cite">In
all fairness, since I have generated and tested code for one
way to solve the problem, can you then give us your code
proposal for generating the SRAM write signal, with 25MHz and
75MHz generated by a DCM? The write signal must be asserted
after all other SRAM control signals are valid, and be
de-asserted before any of the control signals go invalid, and
last for at least 5 nS. The SRAM control signals are
generated by the 25MHz clock and last for one clock cycle. <br>
<br>
I will be more than happy to try it out on a board and report
the result. <br>
<br>
Magnus <br>
<br>
<br>
On 2/19/2016 4:57 AM, Walter Gallegos wrote: <br>
<blockquote type="cite">Have a solid and coherent clock
distribution is basic for FPGA design, my proposition was
keep both 25MHZ and 75MHZ, generated by DCM. <br>
<br>
Run all in 75 MHZ is unnecessary; also, clock enable
approach add unnecessary complexity to the design. Make a
design synchronous don't necessary means use the same clock
for all the design. <br>
<br>
Continue using 25MHZ for the core and peripherals, the only
concern is the CDC (clock domain crossing). As both clock
was generated by the same DCM is minor problem;
correspondent rising edges are aligned by design in DCMs;
metastability is not an issue. Using DCMs and constraining
input clock (50MHZ) the constraints propagation rules
constraint both clocks, 25MHZ and 75MHZ. If no methodology
errors all design are constrained from first to last
register element in the chain. Beware of combinational logic
in outside this elements. <br>
<br>
In my opinion, taking care of CDC keep both clock is the
appropriate solution. <br>
<br>
Best regards, <br>
Walter <br>
<br>
El 2016-02-18 a las 19:58, Magnus Karlsson escribió: <br>
<blockquote type="cite">So I have been thinking about this
some more and decided to modify/update the design to
remove all the concerns raised by Walter and Wojtek. <br>
<br>
Just to recap, Walter's concern is that the clocks are
generated using flip-flops and use logic fabric
interconnect instead of dedicated clocking elements and
pathways, and that all clocks should be generated by a DCM
module instead (DCM = Digital Clock Manager). Wojtek's
concern is that there are unspecified timing relations
between the 25MHz and the 75MHz clock domains. <br>
<br>
Both concerns are valid and in my opinion the correct way
to fix both issues is to make the design completely
synchronous. This means that all clocked elements in the
design (like flip-flops, memories etc.) should be clocked
with a single clock signal, which in this case is the
75MHz clock. The CPU and I/O subsystem, which before was
clocked by a separate 25MHz clock, are now also clocked by
the 75MHz clock but are only enabled to be clocked on
every third clock cycle. This means that all "always @
(posedge clk)" statements have been changed to include "If
(enable) ...", where "enable" is a signal that is true on
every third clock cycle. The asynchronous SRAM interface
is also changed so that the write signal is asserted on
the middle-third clock phase of the three clock CPU cycle.
<br>
<br>
While the Verilog changes to do this are very straight
forward, one complication here is that the Xilinx ISE tool
used to create the bit file for the FPGA do not understand
that the CPU and I/O subsystem are only clocked on every
third clock and will basically try to make the CPU run at
75MHz, and will fail since this is too fast the FPGA. The
solution to this problem is to tell the tool that all
clock paths in the CPU and I/O subsystem can actually take
three clocks to complete (this is called multi-cycle
paths). With the multi-cycle paths added to the .ucf file
the design compiles with no timing violations <br>
<br>
With those changes the 75MHz clock is now generated by a
DCM and the unspecified timing relations that Wojtek
brought up are now gone since everything is clocked with a
single clock. The modified design have been tested on
Pepino and seems to run fine. <br>
<br>
The complete ISE project with those changes are available
at the Pepino GitHub repository: <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino"><a class="moz-txt-link-freetext" href="https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino">https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino</a></a><br>
<br>
Any comments or critique are welcome. <br>
<br>
Cheers, <br>
Magnus <br>
<br>
<br>
<br>
On 2/17/2016 2:16 PM, Walter Gallegos wrote: <br>
<blockquote type="cite">Hi Magnus, <br>
<br>
You are welcome to continue with FPGA specific topics by
private e-mail if you want. <br>
<br>
Regards <br>
Walter <br>
<br>
El 2016-02-17 a las 18:30, Magnus Karlsson escribió: <br>
<blockquote type="cite">Hi Walter, <br>
<br>
Since this is really Paul's design, I guess it would
be more appropriate to discuss it with him, I was just
trying to explain why it looks like it does. <br>
<br>
Cheers, <br>
Magnus <br>
<br>
<br>
On 2/17/2016 1:15 PM, Walter Gallegos wrote: <br>
<blockquote type="cite">Magnus, <br>
<br>
Some of messages was delayed; so, I continue from
here to not overload the list. <br>
<br>
If I understand you correctly, you justify a
uncontrolled delay because they simplify the SRAM
handling. <br>
Sorry, is as using the old circuit with an
and/inverted to generate a pulse. If you need a
delayed signal you should use the DCM 90°, 180° or
270° clock outputs and keep all under control, I
think don't need a state machine in this case. <br>
<br>
About ISE warnings, be careful, non warning do not
means good methodology. <br>
<br>
About XILINX docs; really, I don't remember. Doing
training, first as Xilinx ATP and now as independent
consultant, I touch this problem in my trainings.
Have an uncontrolled delay in clock is a big door to
random problems. FPGA design must be synchronous all
times; no exceptions. <br>
<br>
Regards, <br>
Walter <br>
<br>
<br>
El 2016-02-17 a las 14:41, Magnus Karlsson escribió:
<br>
<blockquote type="cite">Walter, <br>
<br>
I agree with you that the "pure" way of doing this
is as you stated, with a DCM to directly generate
both clk and pclk. So how come Paul didn't do
that? It's not like he doesn't know how to use
the DCM, after all the current code generates pclk
from clk using a DCM, and there would probably be
less code to do it like you suggest. No, the
reason for this is very subtle and is easy to miss
if you just take a quick look at the code, and it
has to the asynchronous SRAM interface. <br>
<br>
One of the most critical aspects of using SRAM is
to control the write signal - ideally the write
signal should be asserted after all other control
signals (like address, data, byte-enable, read,
oe) are valid, and should be de-asserted well
before any of the other control signals go
invalid, to avoid spurious writes. However, this
is not that easy to do in a synchronous system
where all signals change at the clock edge. The
most common way to do this is to have a state
machine that is clocked at say 4x the CPU clock so
that you can divided the SRAM access cycle into
several phases and assert the write signal on some
of those phases. <br>
<br>
However, this is not the way Paul choose to do it,
instead he choose to do a less "pure" clock
generation by generating clk from a flip-flop
rather than from a DCM. By doing so, he actually
generates an early version of the clock signal
called clk that is leading the global clock signal
clk_BUFG by the delay of the BUFG buffer. Since
this early version of the clock signal is
generated like any other logic signal, he could
use this signal to gate the write signal to the
SRAM such that write signal will be de-asserted
well before the other control signals (clocked by
clk_BUFG) will change, and thus avoiding the need
to have a state machine controlling the write
signal. The price for this is that the clock
signal is now generated in a less "pure" way, but
still a valid way as long as you know what you are
doing. The BUFG clock driver can be driven from a
PLL, a DCM or from the logic fabric. The first
two are speed optimized paths going directly from
the PLL or DCM to the BUFG and can be clock at
much higher clock rate, while the logic fabric
path is limited by the maximum clock rate of the
logic fabric. However, at the clock rate we use
(25 MHz) this is not an issue. When you do this
there are no warnings generated by ISE that this
is not a good idea, and I have not read anywhere
in the Xilinx clocking resource guide that you
should avoid doing this. Basically, the BUFG clock
driver is designed to do this, the tool will allow
you to do it and at the clock rate we use it has
no performance implications. As I see it, this is
another place where the goal of simplification has
driven the implementation of the system at the
expense of a slightly less "pure" clock
generation. <br>
<br>
Just my 2c <br>
<br>
Magnus <br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
-- <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
-- <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>
mailing list for ETH Oberon and related systems <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Walter Daniel Gallegos
Programmable Logic & Software
Consultoría, Diseño, Entrenamiento.
Montevideo, Uruguay
EMAIL <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:walter@waltergallegos.com">walter@waltergallegos.com</a>
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.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Walter Daniel Gallegos
Programmable Logic & Software
Consultoría, Diseño, Entrenamiento.
Montevideo, Uruguay
EMAIL <a class="moz-txt-link-abbreviated" href="mailto:walter@waltergallegos.com">walter@waltergallegos.com</a>
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.
</pre>
</body>
</html>