i am trying to turn a led on and off by fpga but IO properties of reg(s) is set to 'OFF' which is output flip flop!
My question is that how can I set IO register to NO in ISE?
I have tried this :
inst "led_error" IOB = false;
but nothing changed.
thanks in advance.
There is a routing options to push FFs into the pads which you can switch on or off. (In ISE it is a stand alone placement option, I have not found it in Vivado yet.)
BUT!!!!
In a previous question you mentioned that two of your the I/Os (which happen to have the 'OFF' attribute) don't work. The OFF is unlikely to be the source of that problem. All what he routing tool did was take an existing internal FF and move it into the pad to improve I/O timing.
I suggest you start looking elsewhere why your output does not work. e.g. check the clock which goes to the FFs which drive the outputs.
I re-awakened my old ISE program and as expected found it under the map settings (Right click on "Map" and select "Process Properties..."):
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'm on Xilinx ISE IDE and using the Schematic Editor.
(click for new window)
The constraints file is following:
NET "A" LOC = M18;
NET "F" LOC = P15;
NET "B" LOC = M16;
NET "A" PULLUP;
NET "B" PULLUP;
NET "F" DRIVE = 8;
But when I want to compile my program, there is this error:
ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found
that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
IOB component <B> is placed at site <M16>. The corresponding BUFG component
<B_BUFGP/BUFG> is placed at site <BUFGMUX_X2Y3>. There is only a select set
of IOBs that can use the fast path to the Clocker buffer, and they are not
being used. You may want to analyze why this problem exists and correct it.
If this sub optimal condition is acceptable for this design, you may use the
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a
WARNING and allow your design to continue. However, the use of this override
is highly discouraged as it may lead to very poor timing results. It is
recommended that this error condition be corrected in the design. A list of
all the COMP.PINs used in this clock placement rule is listed below. These
examples can be used directly in the .ucf file to override this clock rule.
< NET "B" CLOCK_DEDICATED_ROUTE = FALSE; >
ERROR:Pack:1654 - The timing-driven placement phase encountered an error.
How to fix it?
While any signal can theoretically be used as a clock, it's not true for FPGA; at least not optimally. Clocks need special considerations that translate to restriction on which pin of the FPGA can be routed to the clock network.
I suspect that in your case, you used a push-button to act as a clock signal, which will only work on a very small design (like yours) because of debouncing and the fact that it's not a clock-enabled input port.
You can tell the tool that you want the sub-optimal and potentially erroneous clock path by adding the following constraint to your .ucf:
NET "B" CLOCK_DEDICATED_ROUTE = FALSE;
Keep in mind that you shouldn't do that without being sure that your design is fine with it... I recommend that you do further design with a "real" clock connected to a clock port on your FPGA, every board has one. That constraint will make your design work, but in a larger, faster design is likely to be a source of problems.
I am using Cadence's Ethernet eVC wherein the agent's monitor is tapped at the following signals:
. ____________ _____
.clk _____| |__________________|
. ________ _______ ________________ _________
.data __0a____X___07__X_______0b_______X_________
. ^ ^
It samples data at the rising and falling edges of the clock. In the example above, the data 0x07 is garbage data, and the valid values are 0xa (clk rise) and 0xb (clk fall). However, the monitor is sampling (for clk fall) 0x7!
I'm suspecting this is a Specman-simulator synchronization issue. How can this be resolved if it is?
Simulator - IES 13.10
irun 13.10 options - (I'll include here only those which I think could be relevant to the issue, plus those which I've no idea yet what their purpose is)
-nomxindr
-vhdlsync
+neg_tchk
-nontcglitch
+transport_path_delays
-notimezeroasrtmsg
-pli_export
-snstubelab
Languages - VHDL (top testbench), Verilog (DUT), Specman (virtual sequence, Enet and OCP eVCs)
Time between 0x07 (left ^ in the waveform above) and falling edge of clock (right ^) = 0.098ns
One colleague suggested using -sntimescale, but I still can't imagine how that is causing/would resolve the issue. Any of these search strings were not showing helpful hints, even those articles from Cadence: "specman tick synchronization delta delay timescale precision"
This could be indeed an issue of timescale.
There is a comprehensive cookbook talking about deugging specman simulator interface synchronization issues. please take a look here.
To check what is the timescale used in your simulation, you can add -print_hdl_precision option to irun to print the precision for the VHDL hierarchy. For Verilog, it will be printed automatically in case it is set either in the code or via irun options. the information will be printed during elaboration.
To check the timescale used by Specman, you can issue the following command from Specman prompt:
SN> print get_timescale()
Another option to try (only after the timescale option doesn't help) is to remove the -vhdlsync flag. Indeed in most of the mixed environments you should add this flag. But there are rare cases in which the environment works better without it. If you try removing this flag, just remember to re-elaborate.
If you don't find the solution for your problem in the cookbook, deeper investigation should be done. for example, how does specman samples the signal. is it a simple_port, event_port, tick access, etc.. also some trace and probe commands could be helpful. In such case, I suggest to contact Cadence support.
Good Luck!
Semadar
I've got a STM32L-Discovery Board, which has got a STM32L152R8 microprocessor. I'm quite stuck trying to make basic things work.
I've looked the examples given by ST (the current consumption touch sensor and the temperature sensor), and I think they aren't user-friendly, with so many libraries, sub-processes and interrupts, that make the code really difficult to understand.
I've tried to turn on the blue LED (GPIO PB6), but I can't manage to do that.
My code compiles correctly but does nothing to the board. This is the code of "main.c".
RCC->AHBRSTR = 0x00000002;
RCC->AHBRSTR = 0x00000000;
RCC->AHBENR = 0x00000002;
GPIOB->MODER = 0x00001000;
GPIOB->OTYPER = 0x00000040;
GPIOB->OSPEEDR = 0x00001000;
GPIOB->PUPDR = 0x00000000;
GPIOB->ODR = 0x00000040;
while(1) {}
Am I missing something? Could I find really basic examples somewhere?
Thanks in advance!
The standard peripheral library that ST supplies on their website is a good starting point. It has examples on programming a GPIO. Note that their code is absolutely horrible, but at least it works and is something to start with.
What compiler/debugger are you using? If you are using IAR, then you can view the GPIO registers while stepping thru the code. Please post the values of the GPIO registers to your question and maybe we can help.
RCC->AHBENR = 0x00000002;
Change to "RCC->AHBENR |= 0x00000002;"
This will ensure you enable GPIOB without disabling everything else. The existing code will disabled important things like the flash memory controller and all the other GPIOs.
GPIOB->MODER = 0x00001000;
// This will set pin 6 as output, and all other pins as input. Was this your intent?
Change to "GPIOB->MODER = (GPIOB->MODER & 0xFFFFDFFF ) | 0x00001000;"
This will set pin 6 as an output without changing the configuration of any other pins.
GPIOB->OTYPER = 0x00000040;
// This will set the output type as open drain, meaning you can only pull the line down.
Change to "GPIOB->OTYPER |= 0x00000040;"
Set output as push-pull instead of open drain. You later code attempts to set this line high which will not work as an open drain output will pull to ground or allow the line to float. A push-pull output will allow you to set the line high or low.
I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!