Instead, if I set the output frequency to a lower value, like 20 MHz, then I just got the last warning (No nets matched āswclk_IBUFā). Also I donāt get timing violation.
If you want to replicate the bitstream generation, hereās the Github link with all the sources. The Vivado project is in the directory āCW305_DesignStartā.
Iāve uploaded the generated bitstream to CW305 in this notebook.
Hmm that first error is interesting. Iāve never come across this, and yet Iāve done this (generate a Vivado IP block and instantiate it in Verilog) so many times.
Looking at your Vivado project, this is where Vivado is trying to pull in the clock wizard block; is it the right path?
If you can resolve this, all the other errors should go away.
Hi, thanks for the reply.
Iāve changed the path to refer to the correct one, but I still have the same error. Is there some workaround?
You can check the updates still on the github link.
Iāve added a readme describing all the steps Iāve done.
Also, how the block diagram of the clock_and_resets block should look like?
From the readme, mine looks the same as expected.
The clock_and_resets block diagram looks correct (the clk_select.v and clk_wiz_0 modules donāt reside there, despite their names).
Iām puzzled that you keep getting this error. There are reports about this problem on the Xilinx support forum, but Iāve never run into it myself (despite instantiating clock wizard blocks in pretty much all of my projects), and I havenāt been able to find a nice clean solution from those who have encountered this.
One option to avoid this issue altogether is to use this earlier version of our DesignStart recipe, prior to the addition of the clk_select module. Functionally, all you will lose is the ability to bypass the PLL, which only matters if youāre interested in clock glitching.
Looking around it seems that the problem is that the clock wizard does not support the XCI inferring.
A couple of forum topics talk about this (here and here).
Iāve tried some of the fixes suggested, but none of them worked. The only one I didnāt try was to use the IP packager to create a new IP from the clock wizard RTL files.
In the Vivado documentation, chapter 14 (XCI Inferencing) says that even if it cannot be added as an XCI, it should be at least possible to add it as an RTL module. But it didnāt work for me.
Anyway, with another version of Vivado (2023.2) I was able to add the clk_select_0 module in the clock_and_resets block diagram. I donāt know if the bug was due to the Vivado version or to the revision of the clk_wiz IP (upgraded from Rev.3 to Rev.13).
But, now I donāt know how to connect the clk_select_0->sys_clock to the sys_clock input pin.
Since Iām a novice in Vivado, surely Iāve been mis-interpreted some steps.
Here is the list of actions Iāve performed :
Following the readme Iāve tried to add the clk_select module, but since the source is added later on the readme, there was no module.
Iāve added the source files clk_select.v. When I tried to add the module it showed as incompatible
I created the clock wizard IP and then the clk_select module is shown as compatible. With Vivado 2019.1 I got the error, while with Vivado 2023.2 I can add it
I donāt know if it is the correct flow of operations. Do you see something wrong?
Also, If I added the clk_select module correctly how do I connect the clk_select_0->sys_clock to the sys_clock input pin?
But thatās not true - I know because Iāve done it! Iām quite puzzled why itās not working for you; Iām sorry I donāt have a perfect solution, but the workaround I mentioned above (using an older version of our recipe) would avoid the issue entirely; as long as you donāt care about clock glitching, you wonāt lose anything (and if you do care about clock glitching, then you can simply remove the clk_wiz block entirely; however I would still recommend that you start with our approach, to start with a known working point).
I also advise against using the newer Vivado version: when you get to the SW building steps, you wonāt be able to follow along unless you use the version we prescribe.
Hi,
from what I understood the clk_wiz should support the XCI inferring. Itās just that my version of Vivado or the specific revision of the clk_wiz (mine is rev.3) that Iām using has some kind of bug.
What puzzles me though is whether I have followed the steps correctly.
I mean, even if Iām able to add the clk_select module, how am I supposed to connect the clk_select_0->sys_clock to the sys_clock pin?
Am I not trying to connect the output of a sub-module (clk_select) to the input port of the top-level module (clock_and_resets)?
Shouldnāt it be the other way around?
Indeed, Vivado doesnāt allow me to make this connection
Anyway, Iāll try to use the older version of CW305_DesignStart and Iāll keep you updated.
Thanks again for the reply
Hi,
Iāve been able to solve the problem with the clock not toggling.
The error was due to the frequency of the PLL.
I canāt understand why, but by setting the PLL with frequency lower than 15 MHz the soft core stays in the reset state. Maybe the PLL doesnāt work reliably with a frequency lower than 15 MHz.
Instead, with frequency higher the soft core works correctly.
You can check the notebook Iāve used here
Also, Iām using the older version of the CW305_DesignStart (as suggested ), since in my case the newest version doesnāt work (still the problem of not being able to infer the clk_select module ).
Capturing the power trace, this is what looks like :
Now Iām facing a new problem, Iām not able to communicate with the soft-core via UART since Iām using as scope the picoscope.
Can the USB connection be used to exchange data with the softcore?
Thanks again in advance
In general PLLs need to know what input clock frequency theyāre getting in order to function properly. In this case itās supposed to be 20 MHz.
Yes, all communication with the FPGA target is done over the CW305ās USB interface. In the setup notebook, simply replace scope in the target connection command by None: ftarget = cw.target(None, cw.targets.CW305, bsfile=bitstream, force=False)
Yes, Iām doing it already in the notebook, like ftarget = cw.target(None, cw.targets.CW305, bsfile=bitstream, force=True)
But if I try to communicate with the soft-core with ftarget.fpga_write() or ftarget.fpga_read() functions I read always 0. (Check the notebook capture loop block).
Indeed, the led6 (the one associated with UART activity) is always off.
From the constraint file, the UART and trigger signals are associated with IO1, IO2, IO4 pins of the 20-pin connector (here).
What should I do?
I was thinking of using an Arduino to drive these pins. Where the Arduino implements the UART protocol used by the soft-core ( BaudRate : 38400, data bits : 8, No parity).
If I do this, should I send the message as the simple serial does here?
Like : command_char + ascii_encoded_bytes + \n
Is there an easier way ? It would be great to just use the USB interface to communicate with the soft-core.
Every hint is very much appreciated.
If it is out of the scope of this post, I can do a new post reposting the question
Ah sorry, I replied too fast and got my wires crossed, and I hadnāt looked at your notebook - sorry for the confusion.
First, with the older version of the repo that you used, there are no FPGA registers to read or write via ftarget.fpga_read/write().
Second, all communication to the Arm core is via UART, and ftarget.simpleserial_write is ultimately just a wrapper to fpga_write(), so you donāt want to call that - itās meant for āhardwareā CW305 targets (like this), not for soft cores.
What I try to explain here is that this soft-core target can be exercised in the same way as our ānormalā microprocessor targets using e.g. these notebooks. In these notebooks, communication with the target is done over UART, on the CW305ās 20-pin connector which is meant to be connected to CW capture hardware (CW-lite/nano/pro/husky).
Yes, that should work.
Unfortunately no (at least not out-of-the-box; what you could do is add a UART-to-USB translation interface to the FPGA, but thatās probably more trouble than itās worth). The easier way would be to use a CW capture device.
