I am trying to understand some warnings I get in Altera's TimeQuest.
I started with the following constraints in my .sdc file
set_output_delay -clock clk -max 3 [get_ports {data[*]}]
set_output_delay -clock clk -min 1 [get_ports {data[*]}]
It gave me warnings like
set_output_delay has replaced one or more delays on port "data[0]". Please use -add_delay option.
My understanding was that even though a min and max delay is specified the second constraint will override the first constraint.
So I tried
set_output_delay -clock clk -max 3 [get_ports {data[*]}]
set_output_delay -clock clk -min 1 [get_ports {data[*]}] -add_delay
This still gave me the same warning as before. Only if I applied add_delay to both:
set_output_delay -clock clk -max 3 [get_ports {data[*]}] -add_delay
set_output_delay -clock clk -min 1 [get_ports {data[*]}] -add_delay
did the warning go away.
What I do not understand is why I get these warnings when I use add_delay only on the second min constraint. I have no other constraints for this port in the design.
I found out the reason behind this.
The problem was that I reread the SDC file without first resetting the design. All the constraints got reapplied and of course there was warnings.
Resetting the design in TimeQuest and then rereading the SDC file did not cause any warnings.
Related
how do you simulate the RTI (Real Time Interrupt) in the 68HC11 THRSim11 simulator (see http://www.hc11.demon.nl/thrsim11/thrsim11.htm)? the following program works at the 68HC11 module but not in THRSim11. It's a test program to read from Analog to Digital Converter and display results to serial port using RTI. I tried the RTI interrupt vector 00EB and FFF0. My chip is the 68H711E9 with the following memory map.
I expected the THRSim11 to simulate the interrupt vector. When running the "again BRA again" just before CLI (enable Interrupt). It must be running the subroutine that reads from ADC and display to serial. It works perfectly in my 68HC711E9 Evaluation board with buffalo
REGBS EQU $1000 ;start of registers
BAUD EQU REGBS+$2B ;sci baud reg
SCCR1 EQU REGBS+$2C ;sci control1 reg
SCCR2 EQU REGBS+$2D ;sci control2 reg
SCSR EQU REGBS+$2E ;sci status reg
SCDR EQU REGBS+$2F ;sci data reg
TMSK2 EQU REGBS+$24 ;Timer Interrupt Mask Register 2
TFLG2 EQU REGBS+$25 ;Timer Interrupt Flag Register 2
ADR3 EQU $1033 ;ADC address 3
OPTION EQU $1039 ;ADC enable
SCS EQU $2E ;SCSR low bit
ADCTL EQU $1030 ;ADC setting
ADCT EQU $30 ;ADC setting low bit
PACTL EQU $1026 ;Pulse Accumulator control
***************************************************************
* Main program starts here *
***************************************************************
ORG $0110
* ORG $E000
start LDS #$01FF ;set stack pointer
JSR ONSCI ;initialize serial port
JSR t_init ;initialize timer
CLI ;enable interrupts
again BRA again
************************************************************
* t_init - Initialize the RTI timer
************************************************************
t_init LDAA #$01 ; set PTR1 and PTR0 to 0 and 1
STAA PACTL ;which leads to an RTI rate of 8.19 ms
LDAA #$40
STAA TFLG2 ;clears RTIF flag (write 1 in it!)
STAA TMSK2 ;sets RTII to allow interruptssec
RTS
************************************************************
* ADC_SERIAL - timer overflow interrupt service routine
************************************************************
ADC_SERIAL
LDX #REGBS
LDAA #%00010010
STAA ADCTL
LDAB #6
ADF00 DECB
BNE ADF00
ldaa ADR3 ; read ADC value
ldab SCSR ; read first Status
staa SCDR ; save in TX Register
BUFFS BRCLR SCS,X #$80 BUFFS
CLRFLG LDAA #$40
STAA TFLG2 ;clear RTIF
RTI ;return from ISR
************************************************************
* ONSCI() - Initialize the SCI for 9600
* baud at 8 MHz
************************************************************
ONSCI LDAA #$30
STAA BAUD baud register
LDAA #$00
STAA SCCR1
LDAA #$0C
STAA SCCR2 enable
LDAA #%10011010 ; enable the ADC
STAA OPTION
RTS
* Interrupt Vectors for BUFALO monitor
* ORG $FFF0 ;RTI vector for microcontroller
*
ORG $00EB ;Real Time Interrupt under Buffalo monitor
JMP ADC_SERIAL ;this instruction is executed every
* time there is a timer overflow
Presumably you mixed up "vector table" and "jump table". The HC11 expects an address at $FFF0, not an instruction.
In contrast, the Buffalo monitor expects an instruction at $00EB.
ORG $FFF0 ;RTI vector for microcontroller
FDB ADC_SERIAL
ORG $FFFE ;Reset vector for microcontroller
FDB start
As you will note, the same holds true for the reset vector at $FFFE.
With these changes it works for me. Be aware that the simulation is really slow*, depending on the number and kind of views opened.
Another side note: You send the single byte of conversion result without further processing. The serial receiver view of the simulator will try to interpret this byte as an ASCII character, and only if it fails, show a decimal number in angles. You might want to consider to convert the conversion result into a human readable value. The most simple solution may be a hex representation.
EDIT:
*) A simulator needs to be factors faster than the original machine, depending on the specific implementation of the simulation. In this case, they seem to have used a quite slow way. The documentation has some words on this. To gain some speed, close any view you don't need, and use the fastest PC you can get. To gain some understanding, think about how slow a simulation would be if it will simulate the analog electronics with each semiconductor of the chip. And even that is just a model, the "real" world currently starts at quantum mechanics.
Without further measure, you cannot use Buffalo's jump table entries, because the Buffalo monitor is not included in the simulator.
If you want to use an unmodified version of your firmware, you will need to add at least the used parts of the Buffalo monitor. If you have the monitor as a file loadable by the simulator, you might want to load it before loading your application.
The least you could do is to provide the jump table yourself, placing the appropriate address of the jump in the vector:
ORG $FFF0 ;RTI vector for microcontroller
FDB $00EB
The "problem" with the ASCII interpretation becomes visible, if values of printable characters are sent. Put the slider in the first third, and you will see some letter or digit or punctuation. Slide it minimally up and down for other characters. Yes, terminals can be dumb, and this one is no exception. Actually it is a little bit smart and shows the printable characters instead of their ASCII value. Additionally it knows at least CR (carriage return, $0D, decimal 13) and LF (line feed, $0A, decimal 10). You might want to write a little test program that sends "Hello, world", CR, LF. Or another experiment that sends all values from $00 to $FF.
The meaning of a value always depends on its interpretation. This terminal interprets values as ASCII characters, if possible.
I'm at my wit's end here. I'm using 2 different sensors. When the first sensor is triggered, I want to blink a yellow LED one time per second. When the second sensor is triggered, I want to blink a red LED two times per second. I am able to do this one at a time, which is ok, but I cannot make the process repeat (as in, I will trigger the first sensor and the yellow LED pattern will play, but triggering that sensor again has no effect. I cannot trigger the other sensor either unless I close the program and restart. Please note the following code is in Micropython on an ESP8266-12E.
import uasyncio as asyncio
import machine
import time
import os
# Yellow LED: Pin 15
Y_LED = machine.PWM(machine.Pin(15))
Y_LED.freq(300)
# Red LED: Pin 2
R_LED = machine.PWM(machine.Pin(2))
R_LED.freq(300)
H2_1 = machine.Pin(9, machine.Pin.IN, machine.Pin.PULL_UP)
H2_2 = machine.Pin(4, machine.Pin.IN, machine.Pin.PULL_UP)
async def FlashRed():
for i in range (20):
R_LED.duty(1023)
await asyncio.sleep(0.5)
R_LED.duty(0)
await asyncio.sleep(0.5)
async def FlashYellow():
for i in range (10):
Y_LED.duty(1023)
await asyncio.sleep(1)
Y_LED.duty(0)
await asyncio.sleep(1)
loop = asyncio.get_event_loop()
def Check_Button():
while True:
if H2_1.value():
loop.create_task(FlashRed())
loop.run_forever()
if H2_2.value():
loop.create_task(FlashYellow())
loop.run_forever()
time.sleep(0.1)
while True:
Check_Button()
I would like for the board to display a flashing red LED when pin 9 is high, and then display that flashing red LED until pin 9 is low.
I would also like the board to display a flashing yellow LED when pin 4 is high, and likewise, display that flashing yellow LED until pin 4 is low.
I would like to be able to trigger both the pin 9 red pattern and the pin 4 yellow LED pattern simultaneously or independently.
Currently, I can only do one or the other. The board waits for an input from either pin 9 or 4, which is great. When pin 9 goes high, the board correctly displays the red flashing LED pattern. The pattern repeats 10 times, which is great. But then, after the pattern finishes, I cannot initiate it again, nor can I initiate the yellow flashing LED pattern. If I start with the yellow pattern, I cannot restart the yellow pattern and I cannot start the red pattern. I have to quit the script and start again.
Looping Check_Button() isn't working for me.
Any help at all would be much appreciated. Thank you!
You don't want to call run_forever if you have more things to do, because it will literally run the loop forever, even after the created tasks finish.
I cannot test this, but you can try something like this:
async def Check_Button():
while True:
if H2_1.value():
loop.create_task(FlashRed())
if H2_2.value():
loop.create_task(FlashYellow())
await asyncio.sleep(0.1)
loop.run_until_complete(Check_Button())
I have been on this issue for more than 3 days now after I got my SSD1306 I2C in the mail. I have a Tiny Programmer from Sparkfun, which I use with a breadboard.
This is my pin layout: pin2-->SDA, pin3-->SCL. The documentation on the SSD1306 Arduino library states that I have to use these pins even though I know the SDA is pin5 and SCL is pin7. The power and ground are being jumped to the OLED from the Tiny Programmer.
The main issue I am having is that the OLED is not coming on or displaying the text.
The code I am using for this is:
/**
* Attiny85 PINS
* ____
* RESET -|_| |- 3V
* SCL (3) -| |- (2)
* SDA (4) -| |- (1)
* GND -|____|- (0)
*
* Atmega328 PINS: connect LCD to A4/A5
*/
#include "ssd1306.h"
void setup() {
/* Replace the line below with ssd1306_128x32_i2c_init() if you need to use 128x32 display */
ssd1306_128x64_i2c_init();
ssd1306_fillScreen(0x00);
ssd1306_charF6x8(0, 0, "Line 1. text");
ssd1306_charF6x8(0, 1, "Line 2. Bold text", STYLE_BOLD);
ssd1306_charF6x8(0, 2, "Line 3. Italic text", STYLE_ITALIC);
ssd1306_charF12x16(0, 3, "Line 4. Double size", STYLE_BOLD);
}
void loop() {
}
There is no error message when I compile this and I honestly have no idea what's going on.
I have tried swapping the SDA and SCL and still nothing. I have even used the actual SDA and SCL pins and still nothing. I feel that I am out of options and/or the OLED is broken. I'm just seeing if there is anything else I can do before I try to get a replacement for this? Thank you.
I think you have to use pins 5 and 7 with the attiny85. You also need to use tinywirem.h for I2C communication.
The ATTiny85 I2C pins are pin5(PB0) SDA and pin7(PB2) SCL, the SSD1306 library seems to think they are pin3(PB4) SDA and pin2(PB3) SCL, the demos even have an diagram of an ATTtiny within them showing the incorrect pins. I have used the official pins with no luck. Using the pins they suggest did actually run but just so slowly most would think it was not working. It took minutes to start clearing the screen, and even longer to actually clear it.
I have used the U8g2 library instead, the init entry for the Digispark ATTiny85 works OK for the u8x8 helloworld demo though I could not get many of the demos to compile for the ATTiny85. I am still looking for a better solution.
I use two FIBOCOM G510 GSM modems but one of them returns ERROR in some commands like:
AT+CMGF=1\r, AT+CPIN=? returns ERROR.
But some like ATE0\r, AT+CLIP=1\r, AT+CBAUD?\r returns OK.
I use baudrate 115200.
Q1:ATE0\r
R1:\r\nOK\r\n
Q2:AT+CBAUD?\r
R2:\r\n+CBAUD: 115200\r\n\r\nOK\r\n
Q3:AT+CPIN=?
R3:\r\nERROR\r\n
Q4:AT+CMGF=1
R4:\r\nERROR\r\n
Is there something I should set first or is it simcard issue or modem fault?
My other unit works good but I tested it 3 months ago and I think I would use some additional commands to prepare.
I am confuse what's its wrong?
I checked sim card wiring for 3rd time and I found cardinal mistake. Socket was upside down and even wires was connected to the "right place" it did not comunicate.
After rewiring modem starts to work well.
Q5:AT+CPIN?\r
R5:\r\n+CPIN: READY\r\n\r\nOK\r\n
I'm designing a huge system in a FPGA, operating at system clock 320 MHz.
Certain operations must be performed at slower clock - 160MHz due to long critical paths.
I can introduce a clock enable signal, lets call it CE2, used by registers surrounding such long operations.
According to the old Xilinx documentation: http://www.xilinx.com/itp/xilinx10/books/docs/timing_constraints_ug/timing_constraints_ug.pdf (page 60), I can add a special constraint:
NET CE2 TNM = slow_exception;
NET clk TNM = normal;
TIMESPEC TS01 = PERIOD normal 8 ns;
TIMESPEC TS02 = FROM slow_exception TO slow_exception TS01*2;
defining such multicycle timing constraint.
Unfortunately the above case is not descrbide in newer versions of the documentation,
and especially in documentation for Vivado tools.
Does anybody know how the above problem should be solved in XDC file for Vivado?
The new way of doing multicycle constraints in Vivado specifies the number of cycles rather than the direct period.
You can also use datapath_only constraints for false paths and clock crossings, which are more directly akin to what you used in ISE
This is a datapath_only constraint:
create_clock -period 8.000 -name arbitraryClkName -waveform {0.000 4.000} [get_ports portName];
set_max_delay -from [get_pins {hierarchical_location_source/CLK}] -to [get_clocks arbitraryClkName] -datapath_only 16.000;
Here is an actual multicycle hold command:
set_multicycle_path -hold 2 -from [get_pins {hierarchical_location_source/CLK}] -to [get_pins {hierarchical_location_sink/D}];
Here is the constraint documentation for Vivado 2014.3; you can find multicycle path documentation on page 79:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_3/ug903-vivado-using-constraints.pdf