Basically, this problem is related to mapping the toplevel IO's of either verilog or vhdl to the unused pins of a Xilinx FPGA.
Xilinx's old FPGA compiler, "ISE", used to give you a report of the "pin assignments" that the compiler was able to map to the bitfile, once the compiler was finished generating the FPGA binary file for upload.
However, with Xilinx's Vivado FPGA compiler, I have no idea where this report is located...
Does anybody know where to find the report or what the FPGA compiler actually mapped to the pins of the FPGA after finishing the compilation?
Basically, I want to see that Vivado accepted the IO's that I listed in the Xilinx Constraint file and was able to finishing mapping them to the FPGA pins in the Compiler output bitsteam file.
If you haven't warnings or errors relative to your pins after generating bitstream, Vivado has accepted your pinout.
You can have a view of your pins in Vivado :
- Open your implemented design via the left panel
- Layout -> IO planning (on the top bar)
Related
I completed Anton Potočniks' introductory guide to the red pitaya board and I am now able to send commands from the linux machine running on the SoC to its FPGA logic.
I would like to further modify the project so that I can control the phase of the signal that is being transmitted via the red pitayas' DAC. Some pins (from 7 down to 1) of the first GPIO port were still unused so I started setting them from within the OS and used the red pitaya's LEDs to confirm that they were being set without interfering with the functionality of Anton Potočnik's "high bandwidth averager".
I then set the DDS_compilers' to Phase Offset Programmability to "streaming" mode so that it can be configured on the fly using the bits that are currently controling the red pitaya's LEDs. I used some slices to connect my signals to the AXI4-Stream Constant IP core, which in turn drives the DDS compiler.
Unfortunately the DAC is just giving me a constant output of 500 mV.
I created a new project with a testbench for the DDS compiler, because synthesis takes a long time and doesn't give me much insight into what is happening.
Unfortunately all the output signals of the DDS compiler are undefined.
My question:
What am I doing wrong and how can I proceed to control DACs' phase?
EDIT1; here is my test bench
The IP core is configured as follows, so many of the control signals that I provided should not be required:
EDIT2; I changed declarations of the form m_axis_data_tready => '0' to m_axis_phase_tready => m_axis_phase_tready_signal. I also took a look at the wrapper file called dds_compiler_0.vhd and saw that it treats both m_axis_phase_tready and m_axis_data_tready as inputs.
My simulation results remained unchanged...
My new test bench can be found here.
EDIT3: Vivado was just giving me the old simulation results - creating a new testbench, deleting the file under <project_name>.sim/sim_1/behav/xsim/simulate.log and restarting vivado solved this problem.
I noticed that the wrapper file (dds_compiler_0.vhd) only has five ports:
aclk (in)
s_axis_phase_tvalid (in)
s_axis_phase_tdata (in)
m_axis_data_tvalid (out)
and m_axis_data_tdata (out)
So I removed all the unnecessary control signals and got a new simulation result, but I am still not recieving any useful output from the dds_compiler:
The corresponding testbench can be found here.
I also don't get any valid output when I include the control signals.
The corresponding testbench can be found here.
Looks like m_axis_data_tready is not connected. No data will come out unless that's asserted.
I want to build my own SOC based on the rocket chip without the use a ROCC(arm coprocessor). I checked this useful question: rocket chip on non zynq FPGA
I looked for some detailed documentation but I only found few slides describing the configurations without an actual tutorial.
Thus, I have three questions concerning the image below:
I managed to generate the overall verilog for the tinyConfig, but is it possible to generate only the Rocket Chip, HostIO/AXI Convertor and MemIO/AXIHP Convertor ? if yes how ?
Can a debug interface be added by the rocket Chip generator ?
Where can I change the RAM used in rocket chaip by a RAM of a specific FPGA vendor ?
The verilog generated by rocket-chip can be used in FPGA. You just need to replace the behav_srams.v with the RAM generated in vivado.
In system/Config.scala, You can add class WithJtagDTMSystem to your config to generate debug interface.
I have a circuit created by VHDL code in Quartus II. There I have a state machine. I chose the type of encoding: one-hot. I have 9 states and so I should have 9 flipflops.
Is it possible to watch how Quartus implements them on scheme? I can see only state table.
Another question is how to use the outputs of these flipflops. I need to connect them to leds but I don't know how to find them.
If it's necessary I will add my code.
You can check your state machine in Quartus this way: "Tools" -> "Netlist Viewers" -> "State Machine Viewer"
You have to connect your LED output port(s) of your top level entity to the pins on your FPGA. You have to look up in the user manual of your FPGA which pins are used for LEDs. In Quartus you can choose "Assigments" => "Assigment Editor"
Example:
I'm trying to simulate ICE5LP1K FPGA internal oscillator on ModelSim. My design includes the following instance:
SB_HFOSC OSCInst1 (
.CLKHFEN(1'b1),
.CLKHFPU(1'b1),
.CLKHF(CLKLF)
)
I included sb_ice_syn.v file but have a design loading error:
Error: ../testbench/sb_ice_syn.v(26066): Module 'SB_HFOSC_CORE' is not defined
I'm not able to find SB_HFOSC_CORE module in the lattice installation folder.
Where can I find the missed modules?
Doing ModelSim simulation of a Lattice ICE40 family (ICE5LP1K device) design with PLLs requires that a Verilog model of the PLL is included. This is described in Lattice Application Note AN006 (see "c:\lscc\iCEcube2.2015.04\doc\Modelsim_AN006.pdf" for latest iCEcube2 version) on page 9:
If your design contains PLL, add ABIPTBS8.v and ABIWTCZ4.v in $INST_DIR/verilog. For performing Post-Synth simulation for a VHDL design having PLL, you will require a mixed-language simulator, since the PLL model (ABIPTBS8.v) is available only in verilog format.
If the design contains Hardened IP primitives, add the encrypted Verilog simulation library sb_ice_ipenc_modelsim.v available in $INST_DIR/Verilog.
An alternative is if you write a simple simulation model of the SB_HFOSC_CORE PLL core, and then include this in the simulation, since I assume that your focus is on verification of the remaining design, so you probably only need the PLL to give a usable clock.
It is working now.
I found the missing module in the sb_ice_ipenc_modelsim.v
I've looked over the info on BSCANE2 in http://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf (pg 169 7 Series FPGA Configuration Guide) and I can't quite figure out how to use it based on that descriptions.
I want to be able to use the JTAG port on the KC705 board to shift in some configuration data for our design. I think (based on the description there in the user guide linked above) that the BSCANE2 is what I need to do that... but I really don't understand why all of the pins of the BSCANE2 component seem to have the wrong direction (TDO is an input while all of the other JTAG control sigs like TCK, RESET, TDI are outputs). Initially I had thought that there was an implicit connection from the signals of the JTAG port of the FPGA to the instantiated BSCANE2 component, but that doesn't appear to be the case based on the port directions. I suspect I'm missing some information somewhere and while I have read the docs it's still not clear to me how to actually use the BSCANE2 to do what I'm trying to do.
Any example usage of a BSCANE2 component would be appreciated.
NOTE: the description of the BSCANE2 in the user guide linked above says:
The BSCANE2 primitive allows access between the internal FPGA logic and the JTAG Boundary Scan logic controller. This allows for communication between the internal running design and the dedicated JTAG pins of the FPGA
This sounds exactly like what I need.
Xilinx offers a 8 bit CPU called PicoBlaze that uses a JTAGLoader module to reconfigure the PicoBlaze's instruction ROM at runtime. The JTAGLoader is provided in VHDL for Spartans and Series-7 devices.
But I think JTAG is not a good protocol for data transfer. Especially the JTAG software API is a mess.
What about UART? Most boards have a USB-UART bridge like CP2103 that supports up to 1 MBoud.