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
Hi. i wanted a help from this group.i'am currently working on synthesis and need some articles or material how to proceed with the synthesis. for example.. once we have designed a vhdl code. verified the output in testbench. how do we proceed next. synthesis is the next step if 'am not wrong. we get the synthesis report.. but if i get info on how synthesis is done and the design flow, explaiing the steps to be performed explaiing how to carry out till the design is ported on the hardware. so i can learn and get more idea on the same.. Thanks in advance. HOPE TO GET A GOOD RESPONSE... chears AbbSArticle: 91976
jussij@zeusedit.com wrote: >Jussi Jumppanen >Author: Zeus for Windows Programmer's IDE > > I'm still looking for a Verilog editor that will match BEGIN and END blocks just as they do parenthesis and braces. :-(Article: 91977
The synthesis should be done by the tools that you are using. The synthesis process converts the high level VHDL code into a lower level (standard?) form that can be used by the device fitter to implement the logic. An example of synthesis output would be a set of sum of product equations. One reason to use tools is that they should take care of this for you automatically in addition to performing the minimization and optimization for you. Another reason to use a tool is that the form of the best fit will be device specific depending on the resources available in the device. What development tool platform are you working with and what is your target device? This is unless your assignment is to hand synthesize the code as part of an assignment in a VLSI or some other class. .Article: 91978
Rene Tschaggelar <none@none.net> wrote: : LEDs take giant leaps in terms of brightness and cost, : Together with rising prices for power, it won't take : a decade to replace most light bulbs. LEDs are still not as efficient as some more traditional light sources. Here are some approximate figures: White LED: 25-40 lumens/Watt Fluorescent: 40-90 lumens/Watt HMI: 70-100 lumens/Watt The LED figures are a few months old so there may be better ones now. Richard. http://www.rtrussell.co.uk/ To reply by email change 'news' to my forename.Article: 91979
francesco_poderico@yahoo.com wrote: > Hi Andrew, > from the start menu go in Settings-> control panel > in control panel click on system > in system select the Advanced tab and then click on Envirable variable. > press new and on the name write XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING > and on the value write 1 > > Francesco Just another note. I'm not using 7.1 yet, but in earlier versions I found that you need to set the environment variable in the user rather than system variables list. I think this is the default if you click new before browsing the variables in either list.Article: 91980
Thanks John, Zara, Andy, I would sure go and buy one...but as it is my universities board i might not have to pay for the same... (thats the best part) Cheers Next question is about to come... (as i am starter :)... till then sit tight hee hee) AjArticle: 91981
http://www.xilinx.com/bvdocs/appnotes/xapp685.pdf See page 2. Austin seb_tech_fr wrote: > Hi Austin, > I use an V2P70, which is loaded at 76%. > I don't use any macro for DCM. Which one should I use? > > Concerning placement and routing, all constraints have been met. It's > possible that this part is not constraint enough... > > Additional information. When I use a lighter version of my design > (which is loaded at 20%), it works.. > > >>Austin Leseawrote: > > 21127 would not cause what Sebastien is experiencing (on V4), > >>That concerns itself with a lower than 500 MHz possible CLKIN if the > > >>device has been baked at high Vdd AND high temperature (see the NBTI > > >>white paper). >> >>In actual fact, we saw this effect in HTOL testing with the > > production > >>tester, but have never seen it in actual fact either on the test > > bench, > >>or in any testing done by any customers. >> >>There is a suspicion that the testing done is far too tough, and the > > >>problem only appears on the production tester (which tests to >>700 MHz, >>with a +/- 100 MHz sampling) in its tests to ensure that the DCM > > will > >>operate over all corners of the process, voltage and temperatures). >> >> >>For any device with a DCM: >> >>More likely is that the placement of the DCM affects the timing of > > the > >>paths that are used. >> >>Check all the constraints, and check to see that the global clock >>resources are bring routed properly by looking at the design in FPGA > > Editor. > >>For V2 Pro there are clock macros which are used to minimize the >>possible skew from different DCM locations. If this is V2 Pro, then > > I > >>could see this happening if the macros were not being used. >> >>Austin >> >> >> >>Symon wrote: >> >>Cher Sebastien, >>What part are you using? Virtex4? Have you seen answer 21127? >>HTH, Syms. >> >>"seb_tech_fr" > > <sebastien.coquet@techway-dot-fr.no-spam.invalid> wrote in > >>message news:G-SdnWildOwnJ-HeRVn_vA@giganews.com... >> >>Hi, >>Does somebody know DCM corner issues? My DCM is not running at > > very > >>high clock rate (only 107MHz), so I don't think this issue is >>connected with XAPP685 application notes >> >> >>[/quote:e23a8545fa] > >Article: 91982
Hi,
I am designing a peripheral interface IO chip that implements a
bidirectional bus with a microprocessor. The problem I have is that in
one process, I have the bus as an input (that is forced during
simulaton) and in another process, the bus acts as a output that routes
the inputs to the microprocessor.
When I use the bus as an output, the Modelsim simulation shows
XXXXXXXX in the bus. Is this illegal to do? I have no idea of how to
control the input/output configuration a bidirectional bus. Any help is
highly appreciated. Here's my VHDL code
entity pioprocesses is
port(
CE: in std_logic;
RD: in std_logic;
WR: in std_logic;
A0: in std_logic;
STB: in std_logic;
RESET: in std_logic;
IBF: out std_logic := '0';
INTR: out std_logic := '0';
MICROPROCESSOR_D_BUS: inout std_logic_vector (7 downto 0) bus :=
"ZZZZZZZZ";
INPUT: in std_logic_vector (7 downto 0)
);
end pioprocesses;
architecture Behavioral of pioprocesses is
shared variable writingcontrolbits: std_logic := '0';
shared variable qualifiedread: std_logic := '0';
shared variable readingstatusbits: std_logic := '0';
shared variable readinginputbus: std_logic := '0';
shared variable readingdataregister: std_logic := '0';
signal CONTROL_REG: std_logic_vector (1 downto 0) := "00";
signal DATA_REG: std_logic_vector (7 downto 0) := "00000000";
signal STATUS_REG: std_logic_vector (2 downto 0) := "000";
begin
mainprocess: process(CE, A0, WR, RD, STB) is
begin
writingcontrolbits := NOT(CE) AND A0 AND RD;
readingstatusbits := NOT(CE) AND A0 AND WR;
readinginputbus := NOT(CE) AND NOT(A0) AND WR AND NOT
(CONTROL_REG(0));
readingdataregister := NOT(CE) AND NOT(A0) AND WR AND CONTROL_REG(0);
end process;
writecontrolbits: process(WR) is
begin
if falling_edge(WR) then
if(writingcontrolbits) then
CONTROL_REG(0) <= MICROPROCESSOR_D_BUS(0);
CONTROL_REG(1) <= MICROPROCESSOR_D_BUS(1);
STATUS_REG(1) <= CONTROL_REG(1);
end if;
end process;
readstatusbits: process(RD, INPUT) is
begin
if falling_edge(RD) then
if(readingstatusbits = '1') then
MICROPROCESSOR_D_BUS(0) <= STATUS_REG(0);
MICROPROCESSOR_D_BUS(1) <= STATUS_REG(1);
MICROPROCESSOR_D_BUS(2) <= STATUS_REG(2);
MICROPROCESSOR_D_BUS(7 downto 3) <= "ZZZZZ";
elsif(readinginputbus = '1') then
MICROPROCESSOR_D_BUS <= INPUT;
DATA_REG <= INPUT;
elsif(readingdataregister = '1') then
MICROPROCESSOR_D_BUS <= DATA_REG;
INTR <= '0';
STATUS_REG(2) <= '0';
end if;
end if;
if (rising_edge(RD)) then
if(readingdataregister = '1') then
IBF <= '0';
end if;
end if;
if(RD = '0') then
if(readinginputbus = '1') then
MICROPROCESSOR_D_BUS <= INPUT;
DATA_REG <= INPUT;
end if;
end if;
end process;
end Behavioral;
Article: 91983http://direct.xilinx.com/bvdocs/userguides/ug071.pdf page 69 (1312 bits, of which 12 are the FRAME_ECC syndrome), and continuing and http://direct.xilinx.com/bvdocs/appnotes/xapp714.pdf So a larger device has a number of vertical frames (not just two). Austin Andreas Nett wrote: > Hello everybody, > > I'm working on dynamic partial reconfiguration of Xilinx Virtex-II FPGAs. In all Virtex-Device-Families the smallest (re-)configurable unit is a FRAME. I know that in Virtex and Virtex-II, these Frames are running from the top of the device to the bottom. This means that during reconfiguration of a module in the center of the device, no signals can get from the left side to the right side. > > I heard that in Virtex-4, frames didn't go from the top of the device to the bottom but, that there were upper and a lower frames which could also be addressed separately. This would be helpful, concerning the problem described above. Unfortunately I didn't find any information on this topic in the Xilinx Data Sheets. > > Now, my question is: Are there upper and lower frames in a Virtex-4? Or do Virtex-4 frames look like the frames in Virtex and Virtex-II? > > Thanks in advance AndreasArticle: 91984
Grant, Just because you are learning with an Altera part doesn't mean you are forever relegated to working for, or with those parts your whole career (what a grim thought!). Be sure to also check the Xilinx website for jobs, and to be generic on your resume (ie "worked with FPGAs to solve X problem", not "worked with Cyclone FPGA to solve X problem"). If the interviewer wants the details of which part from which manufacturer, then is the time to go into the gory details. Sure, I'd prefer you used the Xilinx parts in your school, but once you understand FPGAs from one vendor, you are then "trained" for pretty much all FPGAs from all vendors. Since virtually all designs today are done using FPGAs, I feel your career choice is a good one. I kept myself busy (gainfully employed) for 11 years designing with FPGAs before I came to Xilinx and became part of the team that designs the FPGAs themselves. If you had said that you were in an ASIC engineering program, and were looking for work designing ICs, I might have advised you differently. There are very few openings for IC design today: pretty much only those who can afford it, like Xilinx, Intel, and TI. Austin badgrant wrote: > hi, i'm grant, studying computer engineering in university of ottawa. > i'm using altera cyclone II on up3 board with quartus II enviorment. > how is it? is it leading in industry? what kind of job can i get when > i'm done. > > guys, forgive me if i have tons of questions, coz i do care about my > career while i know nothing about it right now. :p >Article: 91985
"Gabor" <gabor@alacron.com> wrote in message news:1132321566.517495.134750@g44g2000cwa.googlegroups.com... > > francesco_poderico@yahoo.com wrote: >> Hi Andrew, >> from the start menu go in Settings-> control panel >> in control panel click on system >> in system select the Advanced tab and then click on Envirable variable. >> press new and on the name write XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING >> and on the value write 1 >> >> Francesco > > Just another note. I'm not using 7.1 yet, but in earlier versions I > found that > you need to set the environment variable in the user rather than system > variables list. I think this is the default if you click new before > browsing > the variables in either list. > Thanks, I use XP so setting the EV's is slightly different but I can add to user or system. I initially added to the user Ev's but there was no effect. Later I added to the system and restarted ISE and found it to work. Although I got through PAR there was still a problem getting the clock to work. Another possible solution suggested by Xilinx is to "insert clock buffers" using the "insert pads" command. I have no idea where this command is applied. Any ideas?? -AndrewArticle: 91986
Thank you for your answers. I installed ISE + EDK 6.2 (without any SP from scratch) on on labtop and it works fine. I guess my desktop is corrupted with all these software install/uninstalls ! "sjulhes" <t@aol.fr> a écrit dans le message de news: 437b395e$0$10968$626a14ce@news.free.fr... > Hi ! > > I installed ISE and EDK 6.2i with SP3, and ISE as a stange behavior. > When I go through steps synthesis, P&R and .bit generation every thing is > ok. > If I launch impact or if I swap to another windows application and back to > ISE, all green marks go back to ? and ISE launches the wholel flow !!!! > It is a big waste of time ! > > Does anyone has a clue ? > > Just one point, there was a ISE 6.3 install on this computer which was not > removed correctly. > > Thank you. > > Stéphane. > >Article: 91987
Hi Austin, when are we to expect 8.1i ? BR Austin Lesea wrote: > http://direct.xilinx.com/bvdocs/userguides/ug071.pdf > > page 69 (1312 bits, of which 12 are the FRAME_ECC syndrome), and continuing > > and > > http://direct.xilinx.com/bvdocs/appnotes/xapp714.pdf > > So a larger device has a number of vertical frames (not just two). > > Austin > > Andreas Nett wrote: > >> Hello everybody, >> >> I'm working on dynamic partial reconfiguration of Xilinx Virtex-II >> FPGAs. In all Virtex-Device-Families the smallest (re-)configurable >> unit is a FRAME. I know that in Virtex and Virtex-II, these Frames are >> running from the top of the device to the bottom. This means that >> during reconfiguration of a module in the center of the device, no >> signals can get from the left side to the right side. >> >> I heard that in Virtex-4, frames didn't go from the top of the device >> to the bottom but, that there were upper and a lower frames which >> could also be addressed separately. This would be helpful, concerning >> the problem described above. Unfortunately I didn't find any >> information on this topic in the Xilinx Data Sheets. >> >> Now, my question is: Are there upper and lower frames in a Virtex-4? >> Or do Virtex-4 frames look like the frames in Virtex and Virtex-II? >> >> Thanks in advance AndreasArticle: 91988
Zara wrote: > On 17 Nov 2005 21:53:05 -0800, "Andy Peters" <Bassman59a@yahoo.com> > wrote: > > >aj wrote: > >> simple question... > >> IMPACT doesn't recognize my xilinx parallel cable IV when downloading > >> projects to the board. > >> I have read in some articles that a power supply is necessary to power > >> up > >> the cable, but there is no power supply or adapter in the box where the > >> > >> cable came. > >> ------Can any one tell me what do i do? as my laptop does not have the > >> socket for the pin > >> that is with parallel cable IV... which i think may be for > >> powering up the cable > > > >The dongle gets its power from the target board. > > > >-a > > > False. Prallel Cable III getsi its power form the target board, but > thisi is not true for Parallel Cable IV. Ah, sorry 'bout that, Chief. I just looked at the Parallel Cable III (is this like Led Zeppelin III?) sitting here and assumed that the IV was similar. -aArticle: 91989
Is there a description of some type on Xilinx' routing resources within its FPGA's? I am currently using a Spartan3 but will probably be using a Virtex on future projects. Are the gory details proprietary info? Specifically, I would like to know how the switching matrix works. And the long lines/short lines...when to use...how they are used...etc. Thanks.Article: 91990
Hi, Your problem has a simple solution. In general I would recomend to look in the literature about modeling 3-state buffers. But simple way to handle bidirectional bus is MICROPROCESSOR_D_BUS<=SOME_SIGNAL when WRITE_TO_BUS='1' else 'Z'. Thus you can read your MP bus whenever writ_to_bus is '0'. Regards, Alex > Hi, > I am designing a peripheral interface IO chip that implements a > bidirectional bus with a microprocessor. The problem I have is that in > one process, I have the bus as an input (that is forced during > simulaton) and in another process, the bus acts as a output that routes > the inputs to the microprocessor. > When I use the bus as an output, the Modelsim simulation shows > XXXXXXXX in the bus. Is this illegal to do? I have no idea of how to > control the input/output configuration a bidirectional bus. Any help is > highly appreciated. Here's my VHDL code > > entity pioprocesses is > port( > > CE: in std_logic; > RD: in std_logic; > WR: in std_logic; > A0: in std_logic; > STB: in std_logic; > RESET: in std_logic; > IBF: out std_logic := '0'; > INTR: out std_logic := '0'; > MICROPROCESSOR_D_BUS: inout std_logic_vector (7 downto 0) bus := > "ZZZZZZZZ"; > INPUT: in std_logic_vector (7 downto 0) > ); > > end pioprocesses; > > architecture Behavioral of pioprocesses is > shared variable writingcontrolbits: std_logic := '0'; > shared variable qualifiedread: std_logic := '0'; > shared variable readingstatusbits: std_logic := '0'; > shared variable readinginputbus: std_logic := '0'; > shared variable readingdataregister: std_logic := '0'; > signal CONTROL_REG: std_logic_vector (1 downto 0) := "00"; > signal DATA_REG: std_logic_vector (7 downto 0) := "00000000"; > signal STATUS_REG: std_logic_vector (2 downto 0) := "000"; > begin > > mainprocess: process(CE, A0, WR, RD, STB) is > begin > writingcontrolbits := NOT(CE) AND A0 AND RD; > readingstatusbits := NOT(CE) AND A0 AND WR; > readinginputbus := NOT(CE) AND NOT(A0) AND WR AND NOT > (CONTROL_REG(0)); > readingdataregister := NOT(CE) AND NOT(A0) AND WR AND CONTROL_REG(0); > end process; > > writecontrolbits: process(WR) is > begin > if falling_edge(WR) then > if(writingcontrolbits) then > CONTROL_REG(0) <= MICROPROCESSOR_D_BUS(0); > CONTROL_REG(1) <= MICROPROCESSOR_D_BUS(1); > STATUS_REG(1) <= CONTROL_REG(1); > end if; > > end process; > > readstatusbits: process(RD, INPUT) is > begin > > if falling_edge(RD) then > if(readingstatusbits = '1') then > MICROPROCESSOR_D_BUS(0) <= STATUS_REG(0); > MICROPROCESSOR_D_BUS(1) <= STATUS_REG(1); > MICROPROCESSOR_D_BUS(2) <= STATUS_REG(2); > MICROPROCESSOR_D_BUS(7 downto 3) <= "ZZZZZ"; > > elsif(readinginputbus = '1') then > MICROPROCESSOR_D_BUS <= INPUT; > DATA_REG <= INPUT; > > elsif(readingdataregister = '1') then > MICROPROCESSOR_D_BUS <= DATA_REG; > INTR <= '0'; > STATUS_REG(2) <= '0'; > end if; > > end if; > > if (rising_edge(RD)) then > if(readingdataregister = '1') then > IBF <= '0'; > end if; > end if; > > if(RD = '0') then > if(readinginputbus = '1') then > MICROPROCESSOR_D_BUS <= INPUT; > DATA_REG <= INPUT; > end if; > end if; > > > end process; > > end Behavioral; > -- AlexArticle: 91991
ALuPin@web.de wrote: > > Open-drain are outputs, not inputs (an I=B2C interface should have bidir > > pins, though, but that's another problem). High-impedance has nothing > > to do with inputs. > > Yes, I know. > > > The usual way is to have an internal signal (called scl_out for > > example) that drives the pin's output enable: > > > > scl <=3D '0' when scl_out =3D '0' else 'Z'; > > > But if I define scl_out permanent '0' the fitter will optimize the > bidirection away. > That is the problem. You can't permanently set scl_out to '0' -- there's your problem! If you DO set it to '0' all the time, then of course the tools go, "ah, scl_out never changes, so we can optimize all this stuff out." scl_out is the output enable. An i2c master uses open-drain outputs for SCL (to allow a slave to insert wait states by pulling SCL down). So your internal SCL logic is really generating the output enable, and one would assume it toggles. If you're doing an I2C slave, and this slave doesn't need to insert wait states, then you can simply make SCL an input. -a > So is there a possibility to define a bidirectional port with > open-drain-output direction > without tristate enable ? >=20 > >=20 > > NicolasArticle: 91992
Stephane, http://www.xilinx.com/cgi-bin/power_tool/power_Virtex4 is a new version of the web power tool, but for the full ISE 8.1i, I think that is still yet to be announced ... soon. Austin Stephane wrote: > Hi Austin, > > when are we to expect 8.1i ? > > BR > > Austin Lesea wrote: > >> http://direct.xilinx.com/bvdocs/userguides/ug071.pdf >> >> page 69 (1312 bits, of which 12 are the FRAME_ECC syndrome), and >> continuing >> >> and >> >> http://direct.xilinx.com/bvdocs/appnotes/xapp714.pdf >> >> So a larger device has a number of vertical frames (not just two). >> >> Austin >> >> Andreas Nett wrote: >> >>> Hello everybody, >>> >>> I'm working on dynamic partial reconfiguration of Xilinx Virtex-II >>> FPGAs. In all Virtex-Device-Families the smallest (re-)configurable >>> unit is a FRAME. I know that in Virtex and Virtex-II, these Frames >>> are running from the top of the device to the bottom. This means that >>> during reconfiguration of a module in the center of the device, no >>> signals can get from the left side to the right side. >>> >>> I heard that in Virtex-4, frames didn't go from the top of the device >>> to the bottom but, that there were upper and a lower frames which >>> could also be addressed separately. This would be helpful, concerning >>> the problem described above. Unfortunately I didn't find any >>> information on this topic in the Xilinx Data Sheets. >>> >>> Now, my question is: Are there upper and lower frames in a Virtex-4? >>> Or do Virtex-4 frames look like the frames in Virtex and Virtex-II? >>> >>> Thanks in advance AndreasArticle: 91993
Chintan wrote: > architecture Behavioral of pioprocesses is > shared variable writingcontrolbits: std_logic := '0'; > shared variable qualifiedread: std_logic := '0'; > shared variable readingstatusbits: std_logic := '0'; > shared variable readinginputbus: std_logic := '0'; > shared variable readingdataregister: std_logic := '0'; > signal CONTROL_REG: std_logic_vector (1 downto 0) := "00"; > signal DATA_REG: std_logic_vector (7 downto 0) := "00000000"; > signal STATUS_REG: std_logic_vector (2 downto 0) := "000"; yikes -- what's with all of the shared variables? -aArticle: 91994
Hi, We're faced with a strange problem ... While investigating a bug in one design, we could only observe that behavior on real board and not in simulation. Using chipscope, we finally traced down the problem by monitoring both write and read port of a FIFO16 configured as 18x1024, using the same rd/wr clocks. That fifo was used in a "weird" way, by setting a ALMOSTFULL threshold very high (but still within spec), so that it turn on very quicly. And what we observed is that we push a data with some parity bits (which are not 'true' parity but some critical control), we continue to push, the almost full goes up (normal), and we still push (we still have plenty of room) and at the same time we re-read but slower (not at each clock cycle) and when we finally re-read the data where the parity bit was set, the data (15:0) are there but the parity bit is not, it's just 0 ... The chipscope 'probes' were tied directly to the fifo signals, no logic in between. That fifo is supposed to cross clock domains but for debugging, we just sent the same clock everywhere. And the behavior of the surrounding logic is consitent with that bit being missed. Instead of using ALMOSTFULL set to a very high value, we used not ALMOSTEMPTY (here since we're debugging with just 1 clock domain, it's ok), and there it looks like we never observe such a miss. Has someone ever observed such a behavior ? SylvainArticle: 91995
-- Creates an ERROR:Place:645 if UCF file LOCs pins to non clock inputs -- cam1_xclk_ibufd_inst : IBUFDS -- port map ( -- O => cam1_xclk, -- to DCM input -- I => gpio_exp_hdr2(7), -- IB => gpio_exp_hdr2(6) ); -- This code didn't help the ERROR:Place:645 / WARNING:Place:644 problem -- Does improve the route if one moves the pins to a clock input -- cam1_xclk_ibufgds_inst : IBUFGDS -- generic map ( -- -- DIFF_TERM => "FALSE", -- Differential Termination (Virtex-4 only) -- -- Above line created a TYPE error -- -- Language Template differs from v4ldl libraries guide. -- -- IBUF_DELAY_VALUE => "0", -- -- Specify the amount of added input delay for buffer, -- -- "0"-"16" (Spartan-3E only) -- IOSTANDARD => "DEFAULT") -- port map ( -- O => cam1_xclk, -- I => gpio_exp_hdr2(7), -- IB => gpio_exp_hdr2(6)); -- This code does not get rid of WARNING:Place:644 but -- does improve the appearance of the internal clock route -- even though the UCF file has the pins LOC to non clock inputs cam1_xclk_ibufd_inst : IBUFDS port map ( O => cam1_xclk_intermediate, I => gpio_exp_hdr2(7), IB => gpio_exp_hdr2(6) ); cam1_xclk_bufg : BUFG port map ( O => cam1_xclk, -- to DCM input I => cam1_xclk_intermediate ); Brad Smallridge aivision.comArticle: 91996
Eric Smith <eric@brouhaha.com> wrote: >> BTW: backticks are deprecated, use $() instead ;) > Deprecated? Why bother? POSIX? Don't know. I think is was ok in the 90ties, but I wouldn't use them in new scripts ;) -- mail: adi@thur.de http://adi.thur.de PGP: v2-key via keyserver Nicht alles was hinkt, ist ein Vergleich.Article: 91997
Has anyone had any problems with Chipscope Pro licenses? I evaluated Chipscope Pro a couple months ago and got my company to buy me a copy. I just got my registration ID and reinstalled using the new ID. Now, when I try to scan the JTAG chain in Chipscope Pro Analyzer, I get the following error: ERROR: Registered product: ChipScope Pro 7.1i Web Eval, Registration ID: XXXXXXXxXXXXX The evalution license has expired. (I X'ed out my real ID) I tried uninstalling and then re-installing with no luck. Does anyone know how to fix this? I have opened a web case with Xilinx and was told to call non-technical support. I called them and they transferred me to technical support where I waited on hold for >20 mins before leaving a message. Thanks, AndrewArticle: 91998
Bob, I'd still say that series termination reduces crosstalk since none of the backward crosstalk of the forward signal gets reflected towards the receiver. So one more contribution is removed. Other than that, I think you're right, thanks for pointing that out! We will see backward crosstalk from the reflected signal - except of course there is some kind of termination at the receiver. I guess I was too generous in my previous statement since in my configuration, backward crosstalk appears to be no big problem at all. According to my simulations, two aggressor lines driven to 3.3V couple into a victim line in the middle no more than 100mV at the receiver. On the scope I see a little more than that, but still well below the threshold. Gunter "Bob Perlman" <bobsrefusebin@hotmail.com> wrote in message news:gfjpn1hb5dr5fsvcbl15utpjjgm9ticrh7@4ax.com... > On Thu, 17 Nov 2005 18:26:49 +0100, "Gunter Knittel" > <knittel@gris.uni-tuebingen.de> wrote: > >>Michael, >> >>I don't know a good book, but a few web sites were helpful >>for me, and may serve as a starting point. >> >>http://www.ek.isy.liu.se/courses/tsek35/files2004/3.wires.pdf >> >>http://www.bolton.ac.uk/mind/corep/sig-int/sig-int-1/lesson1.html#6 >> >>http://www.sp.se/electronics/RnD/reports/EMC/lccalc.pdf >> >>At >> >>http://www.sp.se/electronics/RnD/software/eng/LC-Calc.htm >> >>you can find a tool for computing the mutual inductance and capacitance >>matrices from conductor cross-sections. The matrices can be >>used with PSpice to simulate crosstalk. >>I experienced good agreement between the explicit formulas in the topmost >>reference, the simulations, and later the measurements at the PCBs. >>It appears that with the appropriate design style you can drastically >>reduce >>XT - to a point where it is of no concern any more. I have a bus of >>36 single-ended lines, each wire being 0.1mm (4mil) wide and >>only 0.21mm apart from each neighbor (edge to edge), >>running strictly parallel for >30cm (12"). Rise time is <1ns (ALVCH). >>This appears to be a worst-case scenario, but XT never reaches critical >>levels. >>The important thing is to use a stripline configuration, in which >>inductive >>and capacitive forward crosstalk cancel out. Backward crosstalk can be >>controlled by series termination. >> >>Hope this is of use for you, >>cheers >>Gunter > > Thanks for the list of interesting links and documents. > > I agree with what you said about using stripline to greatly reduce > forward crosstalk. But I don't agree that backward crosstalk can be > controlled with series termination, at least not in a way that's > generally useful. If you have two co-located drivers sending signals > along parallel traces to two co-located receivers somewhere else on > your board, series termination certainly helps control reflections on > both lines. But you'll still see the effects of backward crosstalk at > the receivers between time T and 3T, where T is the one-way line > delay. Give it a try in a SPICE coupled-line simulation. > > By the way, the first edition of "High-Speed Digital Design" got this > wrong. Section 5.7.6 originally suggested that series termination > would improve crosstalk considerably; this has been amended in the > errata (http://www.sigcon.com/errataHSDD.htm). If Howard Johnson can > get it wrong, you know it's tricky. > > Bob Perlman > Cambrian Design Works >Article: 91999
Andrew wrote:
> I have opened a web case with Xilinx and was
> told to call non-technical support. I called them and they transferred
> me to technical support where I waited on hold for >20 mins before
> leaving a message.
Only Xilinx can help you with licensing.
One alternative is to get a return authorization
on the chipscope and use HDL simulation instead.
-- Mike Treseler
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