<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Apologies, Spanish typo in my post. "de" => "the".<br>
<br>
<div class="moz-cite-prefix">El 2016-02-24 a las 11:07, Walter
Gallegos escribió:<br>
</div>
<blockquote cite="mid:56CDB930.50802@waltergallegos.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<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.09030702.00020309@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.08080809.05030903@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 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>
<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>
</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>