Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On 27 May 2004 23:50:12 -0700, usenet_10@stanka-web.de (Thomas Stanka) wrote: >Hello, > >do you know any tool, that would help detecting race conditions due to >asynchronous inputs? I used to use a tool like this when I was at Agilent. It was written in-house (Hi Mark!). [snip] >Are there tools, that would help in such cases? I don't like the idea >to spend hours and days inspecting netlists for asynchronous inputs I >use to ensure, that this failure won't happen a second time. Note that a synthesis tool will sometimes *create* races or glitches (e.g. when a ff used in a sychroniser gets replicated due to fanout - yes, this happened in real-world designs). Such problems *cannot* be caught by inspecting the RTL source; the only way is to look at the post-synth netlist. We ended up using the post-PAR back-annotated VHDL netlist (although I guess Verilog would do just as well). If you try, you could probably write such a tool in a few days, assuming you already know how to program in a text processing language such as Perl. (I suppose you could use C if you must.) It is a fairly simple matter to trace all signals in the netlist back (via combinatorial logic) to either the output of something that is clocked (which Mark called a synchronous element, e.g. ff, bram, SRL), or to a pin. By the time all the feature creep had ended, the tool we used checked for: 1. Any clock gating (i.e. if the clock input of any synchronous element is driven by combinatorial logic). 2. A list of all clocks used. You'd be suprised how often extra clocks turn up, particularly in code written by less experienced engineers. 3. Glitches, which we defined as a synchronous element with data input(s) that could be traced back to more than one source in another clock domain (including pins). 4. Races, which we defined as a synchronous element which feeds more than one synchronous element in a different clock domain. [Note: I don't think this is quite the same as the classic definition of glitch and race, but it was ok for our purposes.] 5. Any use of async set or reset. It would trace all of these back to their ultimate source. (Ideally, this would just be a single pin called "reset" or something similar.) We had the problem of integrating large chunks of design written at multiple sites, and this tool saved lots of time by finding problems that couldn't be found in simulation and would only show up in the lab intermittently (e.g. it crashes once every 500 boots). Indeed, it found several problems before we even had an inkling a problem existed! The majority of our problems were due to cross-clock domain paths inside a single FPGA, but the same issues could apply to signals coming from pins. Prior to the creation of this tool, I estimated about half the debug time on some projects was due to improperly handled cross clock domain signals. Many of the bugs were in "proven" legacy code that had been "working fine" for years. There weren't that many bugs, it's just that they took a long time to find compared with straighforward functional bugs. Regards, Allan.Article: 70051
On Sun, 30 May 2004 01:11:09 GMT, Philip Freidin <philip@fliptronics.com> wrote: >If you dont' have either the address valid signal, or the address >does not stay stable for at least 2 cycles, then you have some real >tough problems to solve. Philip, Thank you, your explanations have made a lot of things clear to me. As this decoder is for the VMEbus, I do indeed have an address valid strobe, and the solution is now actually quite obvious. Regards, LourensArticle: 70052
Hi, all ,
I use syplify to synthesize the following vhdl. it comes out with
warnings for signal BitSync_temp, pnt. It seems from the coding logic it
can't have the mux problem since the assignment conditions exclude each
other...(to my understanding), could you give me some comments , thanks
first.
Warning:
@W: CL113 : Feedback mux created for signal BitSync_temp.
@W: CL113 : Feedback mux created for signal pnt[6:0].
process(Clk, Reset,MaxSearchEn)
variable pnt : std_logic_vector(6 downto 0); -- integer range 87 downto
0; 88= 101 1000
begin
if (Reset = '1') then
pnt := (others => '0');
BitSync_temp <= '0';
....
elsif (Clk'event and Clk = '1' and MaxSearchEn = '1') then
....
if (pnt < "1011000") then
pnt := pnt + '1';
else
pnt := (others => '0');
if (PeakValue(BitWidth+6 downto 3) >= "011111111111" ) then
BitSync_temp <= '1';
else
BitSync_temp <= '0';
end if;
end if;
end if;
end process;
regards,
Jimmy
Article: 70053I'm trying to integrate a custom IP peripheral in MicroBlaze based system. I am facing a problem. I've added the custom peripheral in my design using import peripheral wizard. But i am not able to associate an interrupt handler for it. The following error is appearing. ERROR:MDT - Y:\Sum-term-proj\Test\try6\ctr.mss_temp:50 - interrupt_handler is not a configurable parameter for driver generic I've tried to change mdd file of driver generic. Could someone tell me how i can add any dummy driver other than generic?(The GUI by default shows generic or <NONE> as the drivers) Adding the following line in mdd file of driver generic does not help. PARAMETER int_handler = ctr_int_handler, int_port = ovrfl Neither do the following: PARAM name = int_handler, default = ctr_int_handler, desc = "Name of Interrupt Handler", type = string; PARAM name = int_port, default = ovrfl, desc = "Interrupt pin associated with the interrupt handler", permit = none; Thanks, Pankaj Sharma.Article: 70054
On Mon, 31 May 2004 17:18:57 +0800, "Jimmy" <mljiang@eee.hku.hk> wrote: >process(Clk, Reset,MaxSearchEn) change to >process(Clk, Reset) You don't really want the process sensitive to events on MaxSearchEn, I assume that signal is meant to be a clock enable. Regards, Allan.Article: 70055
On Mon, 31 May 2004 19:53:44 +1000, Allan Herriman
<allan.herriman.hates.spam@ctam.com.au.invalid> wrote:
>On Mon, 31 May 2004 17:18:57 +0800, "Jimmy" <mljiang@eee.hku.hk>
>wrote:
>
>>process(Clk, Reset,MaxSearchEn)
>
>change to
>
>>process(Clk, Reset)
>
>You don't really want the process sensitive to events on MaxSearchEn,
>I assume that signal is meant to be a clock enable.
Also, your clock enabled processes should look something like:
label : process(clk, reset)
begin
if reset = '1' then
...
elsif rising_edge(clk) then
if clk_enable = '1' then
...
end if;
end if;
end process;
Comments:
1. You don't need () around the condition in an IF statement. You're
not writing C (or Verilog)!
2. rising_edge(clk) is a lot clearer than clk'event and clk='1'.
There are some minor semantic differences that probably won't worry
you.
3. Use separate IF statements for the rising_edge and clk_enable
parts. It's easier to read, and some synthesisers may have problems
if they're combined into the one condition.
4. VHDL doesn't force you to label processes, but I find it makes it
easier to read the code if they are labeled, assuming you choose
labels sensibly.
Regards,
Allan.
Article: 70056Anybody knows a good reference with all the specs for the various I/O standards such as: SSTL, HST, GTL, CTT, LVCMOS, LVPCML, LVTTL and others ? I tried everywhere but couldn't find much. Is there some book like Electrical Engineering Reference Book that has these standards ???Article: 70057
On 31 May 2004 07:45:17 -0700, vbishtei@hotmail.com (vadim) wrote: >Anybody knows a good reference with all the >specs for the various I/O standards such as: > >SSTL, HST, GTL, CTT, LVCMOS, LVPCML, LVTTL and others ? > >I tried everywhere but couldn't find much. Is there some >book like Electrical Engineering Reference Book that has >these standards ??? http://www.jedec.org/ might be a good place to start. It also defines things like pinouts on ram modules, etc. Allan.Article: 70058
Please forgive me if I screw up some of the terminology here, I'm new
to actual physical manipulation of hardware...
I'm looking for a quick, cheap solution that will give me some
solderless breadboard space, a socket that I can put an SMT chip into
(probably via some sort of adapter, which is okay), and a Xilinx or
Altera low-end FPGA. A cyclone would probably be ideal since I need
very few gates -- "no FPGA too small" and I'm trying to keep costs
down.
Basically I'm looking for this with an FPGA already on it:
http://www.axman.com/education/edc_hc11.html
I'm looking for this because I just stumbled across a supply of very
cheap (but somewhat nonstandard) GPS chips, and I need to test out the
samples I got before I order more. I'd also like to reuse this board
later for other similar projects.
I'll also need some way of programming the FPGA from a computer; JTAG
or serial is fine, USB would be even better.
Thanks!
- a
--
"The first time I read this book I felt what I could only explain as a
great disturbance in the Force: it was as if a billion washing
machinces all became unbalanced at once and were suddenly silenced."
-- anonymous book reviewer on Amazon.com
Article: 70059It seems to me, the NGDBuild can't differentiate two XCF constraints which are brought in by the NGC files... I put a clock period of 14.58ns in XCF for XST synthesis. Then I put a UCF constraint of 23.085ns for partially P&R on two sides of my XC2V6000...When I started to assemble them, the NGDBuild gave me this error: ERROR:XdmHelpers:682 - Second definition of specification "TS_clk_in" found: first definition: PERIOD:clk_in:14580.000000:pS:HIGH:50.000000% second definition: PERIOD "clk_in" 14580.000000 pS HIGH 50.000000 % WARNING:XdmHelpers:681 - UCF definition of specification "TS_clk_in" overrides the definition found in the netlist or NCF file: UCF: PERIOD "clk_in" 23085.000000 pS HIGH 50.000000 % netlist/NCF: PERIOD:clk_in:14580.000000:pS:HIGH:50.000000% How may I handle this sort of awkward situation? KelvinArticle: 70060
Instead of an FPGA board that includes a breadboard, why not a breadboard where you plug a "DIP" FPGA board? Like this http://www.fpga4fun.com/board_pluto-II.html ? You populate the board sides with headers and it becomes a 24 pins "FPGA DIP chip". You configure it through a PC's serial port. JeanArticle: 70061
rajes_kumar@yahoo.com (Rajesh Murugesan) wrote in message news:<5b293f11.0405241143.1d54258e@posting.google.com>...
> td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0405181256.7895fada@posting.google.com>...
>
> > I have the same requirement and have successfully generated a reset
> > signal for the CLKDLL, so I know it can be done. It looks something
> > like this:
> >
> > dll : CLKDLL port map (
> > CLKIN => clk,
> > CLKFB => clkfb,
> > RST => dll_reset,
> > etc.
> > );
> >
> > dll_reset <= error1 OR error2; -- error1, error2 generated by internal
> > logic
> >
> > Good luck!
> > -td
******
Hi
I tried to generate the reset signal for the CLKDLL, where the reset
signal is generated by internal logic (thnx to Tony!!!).Still I get
errors when I tried to implement the design. If i dont use the reset
pin of the DLL(ie, when the reset pin is tied to ground), there are no
errors. Since there is change in input frequency, manual reset is
mandatory. Device: Spartan II
To Tony: Did you use a change in input frequency and if so..how did
you activate and de-activate the reset signal when there is a change
in input frequency?
CODE:
rst_a, rst_b : signal
f_done_prog, f_start_prog_pll : input
rst_out: output
<<if modu_clk'event and modu_clk = '1' then
if (div16_clk_counter(3)='0' and sclk_div16='1') then
case reset_status is
when rst_boot =>
rst_out <= rst_a OR rst_b;
reset_status <= rst_0;
when rst_0 =>
if f_done_prog_pll ='1' then
rst_a <= '0';
rst_b <= '0';
reset_status <= rst_1;
end if;
when rst_1 =>
rst_out <= rst_a OR rst_b;
reset_status <= rst_2;
when rst_2 =>
if f_start_prog_pll = '0' then
rst_b <= '1';
reset_status <= rst_3;
end if;
when rst_3 =>
rst_out <= rst_a OR rst_b;
reset_status <= rst_0;
end case;
dll : CLKDLL port map (
CLKIN => clk,
CLKFB => clkfb,
RST => rst_out,
etc.
);
**************************
ERRORS:
ERROR:NgdBuild:455 - logical net 'rst_rst_out' has multiple drivers.
The
possible drivers causing this are:
pin Q on block rst_rst_out with type FDE,
pin PAD on block rst_rst_out.PAD with type PAD
ERROR:NgdBuild:466 - input pad net 'rst_rst_out' has illegal
connection.
Possible pins causing this are:
pin Q on block rst_rst_out with type FDE,
pin I0 on block rst__n000812_SW0 with type LUT3
Also..Checked the RTL-schematic and could not find any multiple
drivers or an illegal connection. Am I doing wrond anywhere.
Suggestions please!!!
Thanks in advance.
Regards
Rajesh
Article: 70062I am using xc2s30 -5 pq144 fpga when i am programming through jatag(slave serial using ISE4.2i) this device programmed successfully but when i am trying to configure using prom xc18v02 pc44 the FPGA is not getting configured and the done is not getting high the cclk is coming from FPGA continues and the data from prom is comes power-on we seen on oscilloscope. the init and programme pin high and the cclk is 4mhz coming continues. In prom xc18v series data sheet the recommended prom for xc2s30 is xc18v512 so i want to know can i use this xc18v02 for xc2s30 or i have to use xc18v512 only. I used xc18v02 prom to configure xc2s100 and xc2s200 it is working fine so what is the difference in xc2s30. xc18v02 is recommended for xc2s200 but it is configuring xc2s100 fpga so it should configure xc2s30 also. Thanks.Article: 70063
This is a warning that tells you that the XST / PAR has used the last = constraint set in the UCF file. Xilinx allows multiple constrainst to be set, but if more than one is = used the UCF file will have priority. I think it goes something like EDIF file constraint to NCF file to UCF = file etc. With UCF file setting the priority. i.e. the user can override what an = IP provider has stated in the EDIF or NCF for a particular place and = route run in the UCF. Good Luck ExpressIP LTDArticle: 70064
Yes this is possible.
See our downloadable design examples, specifically the clocks file, I haves
assumed Xilinx and XST flow etc.
This does more than what you want, as it synchronises some external SDRAM
memorys too.
rs_sys comes from an input buffer (IBUF) etc.
Good Luck
----------------------------------------------------------------------------
----------
-- (c) Copyright [2003] ExpressIP Ltd. All rights reserved.
----------------------------------------------------------------------------
----------
-- The copyright in this material is owned by ExpressIP Ltd ("ExpressIP").
--
-- The contents of this file are subject to the ExpressIP License Agreement.
--
-- You may not use this file except in compliance with the ExpressIP Licence
Agreement.
--
-- See the ExpressIP web site for LICENSE Agreement details.
--
-- The ExpressIP Licence Agreement is to be used over and above all other
agreements.
--
-- This source file may be used and distributed subject to the
-- licence and provided this copyright statement is not
-- removed from the file and that any derivative work contains
-- the original copyright notice and the associated disclaimer.
--
-- THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY
-- EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
-- TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
-- FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL THE AUTHOR
-- OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
-- INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
-- (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
-- GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
-- BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-- LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
-- OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-- POSSIBILITY OF SUCH DAMAGE.
--
----------------------------------------------------------------------------
----------
----------------------------------------------------------------------------
----------
--
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
-- synthesis translate_off
LIBRARY unisim;
USE unisim.ALL;
-- synthesis translate_on
ENTITY ExpressIP_clks IS
PORT(
ra_sys : IN STD_LOGIC
; -- System asynchronous reset.
cki_sys : IN STD_LOGIC
; -- 27MHz raw clock in from osc.
ckr_sys : OUT STD_LOGIC
; -- 54MHZ (x2) System clock output for use inside FPGA, clock tree output.
cki_capt : IN STD_LOGIC
; -- capture clock.
ckr_capt : OUT STD_LOGIC
; -- capture clock.
ckr_capt_dir : OUT STD_LOGIC
; -- capture clock direct.
cko_54MHz_1 : OUT STD_LOGIC
; -- 54MHZ (x2) System clock output for use outside FPGA, with sdrams.
cki_54MHz_1 : IN STD_LOGIC
; -- feedback version of cko_54MHz_1 for DLL in EpressIP_clks.vhd, used to
synchronise the clocks.
cko_54MHz_2 : OUT STD_LOGIC
; -- 54MHZ (x2) System clock output for use outside FPGA, with sdrams.
cki_54MHz_2 : IN STD_LOGIC
; -- feedback version of cko_54MHz_2 for DLL in EpressIP_clks.vhd, used to
synchronise the clocks.
op_dlls_capt_locked : OUT STD_LOGIC
; -- indicates the DLL's are settled
op_dlls_locked_extd : OUT STD_LOGIC
; -- indicates the DLL's are settled but delayed so that the pulse can be
used in a state machine etc.
op_dlls_locked : OUT
-- indicates the DLL's are settled.
);
END ExpressIP_clks;
ARCHITECTURE asic OF ExpressIP_clks IS
COMPONENT CLKDLL
PORT (clkin, clkfb, rst : IN STD_LOGIC;
clk0, clk90, clk180, clk270, clk2x, clkdv, locked : OUT STD_LOGIC);
END COMPONENT;
COMPONENT IBUFG
PORT (I : IN STD_LOGIC; O : OUT STD_LOGIC);
END COMPONENT;
COMPONENT BUFG
PORT (I : IN STD_LOGIC; O : OUT STD_LOGIC);
END COMPONENT;
COMPONENT OBUF
PORT (I : IN STD_LOGIC; O : OUT STD_LOGIC);
END COMPONENT;
COMPONENT SRL16E
PORT (D : IN STD_LOGIC ;
CLK : IN STD_LOGIC ;
Q : OUT STD_LOGIC ;
CE : IN STD_LOGIC ;
A3 : IN STD_LOGIC ;
A2 : IN STD_LOGIC ;
A1 : IN STD_LOGIC ;
A0 : IN STD_LOGIC
);
END COMPONENT;
SIGNAL s_ra_sys : STD_LOGIC
;
SIGNAL s_logic1 : STD_LOGIC := '1'
;
SIGNAL s_clk_in_ibuf : STD_LOGIC
;
SIGNAL s_clk_fb_ibuf : STD_LOGIC
;
SIGNAL s_clk_108_ibuf : STD_LOGIC
;
SIGNAL s_clk_dllx2_ext : STD_LOGIC
;
SIGNAL s_dll_locked_ext : STD_LOGIC
;
SIGNAL s_cko_54MHz : STD_LOGIC
;
SIGNAL s_clk_dllx2_int : STD_LOGIC
;
SIGNAL s_dll_locked_int : STD_LOGIC
;
SIGNAL s_clk_a_out : STD_LOGIC
;
SIGNAL s_clk_dllx4_int : STD_LOGIC
;
SIGNAL s_clk_108_out : STD_LOGIC
;
SIGNAL s_clk_dllx4_ext : STD_LOGIC
;
SIGNAL s_op_dlls_locked : STD_LOGIC
;
SIGNAL s_dll_locked_int_dly : STD_LOGIC
;
SIGNAL s_dll_locked_int_dly_inv : STD_LOGIC
;
SIGNAL s_dll_locked_ext_dly : STD_LOGIC
;
SIGNAL s_dll_locked_ext_dly_inv : STD_LOGIC
;
SIGNAL s_op_dlls_locked_extd : STD_LOGIC
;
SIGNAL s_op_dlls_locked_extdd : STD_LOGIC
;
SIGNAL s_dll_locked_108int : STD_LOGIC
;
SIGNAL s_read_addr : STD_LOGIC_VECTOR(3 DOWNTO 0)
;
SIGNAL s_clk_capt_ibuf : STD_LOGIC
;
SIGNAL s_clk_capt_int : STD_LOGIC
;
SIGNAL s_clk_capt_out : STD_LOGIC
;
SIGNAL s_dll_locked_capt : STD_LOGIC
;
BEGIN
s_ra_sys <= NOT(ra_sys) ;
ibufg_i0 : IBUFG
PORT MAP (
I => cki_sys ,
O => s_clk_in_ibuf
);
ibufg_i1 : IBUFG
PORT MAP (
I => cki_54MHz_1 ,
O => s_clk_fb_ibuf
);
ibufg_i2 : IBUFG
PORT MAP (
I => cki_54MHz_2 ,
O => s_clk_108_ibuf
);
clkdll_i0 : CLKDLL
PORT MAP (
CLKIN => s_clk_in_ibuf ,
CLKFB => s_clk_a_out ,
RST => s_ra_sys ,
CLK2X => s_clk_dllx2_int ,
clk0 => OPEN ,
clk90 => OPEN ,
clk180 => OPEN ,
clk270 => OPEN ,
clkdv => OPEN ,
LOCKED => s_dll_locked_int
);
bufg0 : BUFG
PORT MAP (
I => s_clk_dllx2_int ,
O => s_clk_a_out
);
ckr_sys <= s_clk_a_out ;
ExpressIP_pipe_srl16_1_i0 : srl16e
PORT MAP (
CLK => s_clk_in_ibuf ,
D => s_dll_locked_int ,
Q => s_dll_locked_int_dly ,
CE => s_logic1 ,
A3 => s_read_addr(3) ,
A2 => s_read_addr(2) ,
A1 => s_read_addr(1) ,
A0 => s_read_addr(0)
);
s_dll_locked_int_dly_inv <= NOT(s_dll_locked_int_dly) ;
clkdll_i1 : CLKDLL
PORT MAP (
CLKIN => s_clk_a_out ,
CLKFB => s_clk_fb_ibuf ,
RST => s_dll_locked_int_dly_inv ,
CLK2X => s_clk_dllx4_ext ,
clk0 => s_clk_dllx2_ext ,
clk90 => OPEN ,
clk180 => OPEN ,
clk270 => OPEN ,
clkdv => OPEN ,
LOCKED => s_dll_locked_ext
);
obuf_i1 : OBUF
PORT MAP (
I => s_clk_dllx2_ext ,
O => s_cko_54MHz
);
cko_54MHz_1 <= s_cko_54MHz ;
ExpressIP_pipe_srl16_1_i1 : srl16e
PORT MAP (
CLK => s_clk_in_ibuf ,
D => s_dll_locked_ext ,
Q => s_dll_locked_ext_dly ,
CE => s_logic1 ,
A3 => s_read_addr(3) ,
A2 => s_read_addr(2) ,
A1 => s_read_addr(1) ,
A0 => s_read_addr(0)
);
s_dll_locked_ext_dly_inv <= NOT(s_dll_locked_ext_dly) ;
clkdll_i2 : CLKDLL
PORT MAP (
CLKIN => s_clk_a_out ,
CLKFB => s_clk_108_ibuf ,
RST => s_dll_locked_ext_dly_inv ,
CLK2X => OPEN ,
clk0 => s_clk_dllx4_int ,
clk90 => OPEN ,
clk180 => OPEN ,
clk270 => OPEN ,
clkdv => OPEN ,
LOCKED => s_dll_locked_108int
);
obuf1 : OBUF
PORT MAP (
I => s_clk_dllx4_int ,
O => s_clk_108_out
);
cko_54MHz_2 <= s_clk_108_out ;
s_op_dlls_locked <= s_dll_locked_ext;
op_dlls_locked <= s_op_dlls_locked_extd ;
ExpressIP_pipe_srl16_1_i2 : srl16e
PORT MAP (
CLK => s_clk_in_ibuf ,
D => s_op_dlls_locked ,
Q => s_op_dlls_locked_extd ,
CE => s_logic1 ,
A3 => s_read_addr(3) ,
A2 => s_read_addr(2) ,
A1 => s_read_addr(1) ,
A0 => s_read_addr(0)
);
s_read_addr <= (OTHERS => '1' ) ;
ExpressIP_pipe_srl16_1_i3 : srl16e
PORT MAP (
CLK => s_clk_in_ibuf ,
D => s_op_dlls_locked_extd ,
Q => s_op_dlls_locked_extdd ,
CE => s_logic1 ,
A3 => s_read_addr(3) ,
A2 => s_read_addr(2) ,
A1 => s_read_addr(1) ,
A0 => s_read_addr(0)
);
op_dlls_locked_extd <= s_op_dlls_locked_extdd ;
-- capture clock
ibufg_i3 : IBUFG
PORT MAP (
I => cki_capt ,
O => s_clk_capt_ibuf
);
clkdll_i3 : CLKDLL
PORT MAP (
CLKIN => s_clk_capt_ibuf ,
CLKFB => s_clk_capt_out ,
RST => s_ra_sys ,
CLK2X => OPEN ,
clk0 => s_clk_capt_int ,
clk90 => OPEN ,
clk180 => OPEN ,
clk270 => OPEN ,
clkdv => OPEN ,
LOCKED => s_dll_locked_capt
);
bufg1 : BUFG
PORT MAP (
I => s_clk_capt_int ,
O => s_clk_capt_out
);
ckr_capt <= s_clk_capt_out ;
ckr_capt_dir <= s_clk_capt_ibuf ;
op_dlls_capt_locked <= s_dll_locked_capt ; -- indicates
the DLL's are settled
END asic;
ExpressIP LTD
"Rajesh Murugesan" <rajes_kumar@yahoo.com> wrote in message
news:5b293f11.0405172336.39ea9f62@posting.google.com...
> Hi all,
>
> In my design, DLL is used to multiply the input frequency at the
> factor of 2. Since the input source clock is from the external PLL
> (Generates 2 different frequency---Change in input frequency), a
> manual reset is mandatory. When I tried to generate an INTERNAL SIGNAL
> and mapped to the reset signal (RST) of the DLL, there were errors as
> mentioned below:
>
> ERROR:NgdBuild:455 - logical net 'rst_in' has multiple drivers. The
> possible
> drivers causing this are:
> pin G on block XST_GND with type GND,
> pin PAD on block rst_in with type PAD
> ERROR:NgdBuild:466 - input pad net 'rst_in' has illegal connection.
>
> Would the design implementation in FPGA allow the user to map an
> internally generated reset signal to the reset signal of the DLL?
>
> Tool: Xilinx ISE 6.2i
>
> Device: Spartan XC2S200
>
> Eagerly waiting for your suggestions..
>
> Thanks in advance
>
> Regards
> Rajesh
Article: 70065Hello, I am currently working with spartan2E FPGA (series 200). Is there a solution to test a great number of FPGA quickly (in order to make some statistical measurement) ? Simplest would be to use standard PC84 package to clip the various FPGA on an home made test board, but none of the Spartan2E exist in this package. Would somebody have an idea preventing me from welding and unsolder the different FPGA ? I specify that I need only little I/O. ThanksArticle: 70066
I had this problem with leonardo version 2001. I've just changed to leonardo 2002 and it was working well.Article: 70067
I'm converting a NIOS design to a NIOS 2 design. The end product has a large number of 256MBit FLASH devices (19). I've mapped all the periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM 0x0200 0000 (spaces added for clarity) I then start adding FLASH devices at 0x0400 0000. All goes well till I try to place FLASH at 0x1000 0000. I get a compiler error messages: "Address range of instruction master crossing a 256 MByte boundary. Not supported" My questions are: Did I do something wrong? Is this a bug or for real? How can I handle large memory designs? How can I make some of the FLASH data and ont instructin memory and will that help? Thanks GeorgeArticle: 70068
Hi First, excuse me for my english, Im a french student. Then, I have problems to reuse RPM with ISE 6.2i and VirtexE : I have cut a project in macros which are relationnaly placed. I want to reuse those macros in another project but the Translate shows me errors : ------ERROR:NgdBuild:753 - Line 3 in 'emis.ucf': Could not find instance(s) 'b_emisq/b_opp/Madd_s_inst_cy_34' in the design. To suppress this error specify the correct instance name or remove the constraint. or ------ERROR:NgdBuild:753 - Line 4 in 'emis.ucf': Could not find instance(s) 'b_emisq/b_opp/Madd_s_inst_sum_34' in the design... ... The carry logic and sum logic make errors because (I think) during the resynthesise of the macros ISE changes the name of carry logic and sum logic. There's no error with the others logic, and I can reuse all macros which have no carry chain. Do you know those errors and how I can resolve them ? Thank you Yvan EUSTACHEArticle: 70069
"George" <george.martin@att.net> wrote in message news:e9d879fa.0406010629.27219b22@posting.google.com... > I'm converting a NIOS design to a NIOS 2 design. The end product has > a large number of 256MBit FLASH devices (19). I've mapped all the > periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM > 0x0200 0000 (spaces added for clarity) I then start adding FLASH > devices at 0x0400 0000. All goes well till I try to place FLASH at > 0x1000 0000. I get a compiler error messages: "Address range of > instruction master crossing a 256 MByte boundary. Not supported" > > My questions are: Did I do something wrong? Is this a bug or for > real? How can I handle large memory designs? How can I make some of > the FLASH data and ont instructin memory and will that help? > You can choose whether the memory banks are connected to the instruction master and/or the data master. It sounds like there is a limitation in the Nios II regarding the width of instruction addresses (probably so that an absolute call or jump can fit within a single instruction), but that should not affect the data access (presumably this range is mostly data?). Deselect the instruction master connection from the data banks, and see if that helps.Article: 70070
>Anybody knows a good reference with all the >specs for the various I/O standards such as: > >SSTL, HST, GTL, CTT, LVCMOS, LVPCML, LVTTL and others ? FPGA data sheets? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 70071
Cher Yvan, Two suggestions. 1) Use the Floorplanner to find out the new names of the chain, and correct the UCF file accordingly. 2) Put the RLOCs in your source code. i.e. Use VHDL attributes. See the 'constraints guide' in the Xilinx documentation. I've had to do both of these in the past. Bon chance, Syms. <yvan.eustache1@etud.univ-ubs.fr> wrote in message news:c48b3bae.0406010642.57de0c63@posting.google.com... > The carry logic and sum logic make errors because (I think) during the > resynthesise of the macros ISE changes the name of carry logic and sum > logic.Article: 70072
The feedback mux warning comes about because of the condition where
bitsync_temp is not assigned in the if_then potion:
Jimmy wrote:
>
> if (pnt < "1011000") then
> pnt := pnt + '1';
> else
> pnt := (others => '0');
>
> if (PeakValue(BitWidth+6 downto 3) >= "011111111111" ) then
> BitSync_temp <= '1';
> else
> BitSync_temp <= '0';
> end if;
>
> end if;
That structure makes an implied memory element for bitsync_temp in the case
pnt<"1011000". separate the logic for pnt and bitSync_temp into two separate
if then elses to fix the problem as well as to make it more readable.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 70073"David Brown" <david@no.westcontrol.spam.com> wrote in message news:<c9i4bk$3lg$1@news.netpower.no>... > "George" <george.martin@att.net> wrote in message > news:e9d879fa.0406010629.27219b22@posting.google.com... > > I'm converting a NIOS design to a NIOS 2 design. The end product has > > a large number of 256MBit FLASH devices (19). I've mapped all the > > periferrals to low mamory 0x000 to 0x2000 and then one 256 MBit SDRAM > > 0x0200 0000 (spaces added for clarity) I then start adding FLASH > > devices at 0x0400 0000. All goes well till I try to place FLASH at > > 0x1000 0000. I get a compiler error messages: "Address range of > > instruction master crossing a 256 MByte boundary. Not supported" > > > > My questions are: Did I do something wrong? Is this a bug or for > > real? How can I handle large memory designs? How can I make some of > > the FLASH data and ont instructin memory and will that help? > > > > You can choose whether the memory banks are connected to the instruction > master and/or the data master. It sounds like there is a limitation in the > Nios II regarding the width of instruction addresses (probably so that an > absolute call or jump can fit within a single instruction), but that should > not affect the data access (presumably this range is mostly data?). > Deselect the instruction master connection from the data banks, and see if > that helps. Do you know how to do that. I added a 2nd TriState Bus and connected that to the CPU Data Master Bus. The 1st TriSatate bus is connected to the CPU Instruction Master Bus. Is this the best (correct) way?? Thanks GeorgeArticle: 70074
I have a design that runs perfecly fine in ise 6.1 but when i try to implement the design in 6.2 i get a bunch of errors somehow related to pin drive strength and slew rate? i have a diff clock pair that uses io standard lvpecl_25 and a couple signals on different banks that use typical io standards. the errors start in the map sections here is a printout of the log (I changed sensitive variable names to NETNAME, note they were not all the same variable) Using target part "2vp7ff672-7". Removing unused or disabled logic... Running cover... Running directed packing... Running delay-based LUT packing... Running related packing... ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp RTS, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp RTS, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp ser_out, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:350 - Blockcheck: Invalid drive strength. Drive strength must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:DesignRules:352 - Blockcheck: Invalid slew rate. Slew rate must not be set in IOB comp NETNAME, based on its IO standard of LVCMOS25. ERROR:Map:46 - Errors in physical DRC.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z