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
Hello, I seem to have a problem while downloading the design on ML300 trough the JTAG cable. I searched it over the net but found no solution. I can download the design using the compact flash but with JTAG it gives a problem. impact -batch etc/download.cmd PM_SPEC -- Xilinx path component is <C:/EDK> // *** BATCH CMD : setMode -bs // *** BATCH CMD : setCable -port auto AutoDetecting cable. Please wait. Connecting to cable (USB Port). Cable connection failed. Connecting to cable (Parallel Port - LPT1). Checking cable driver. Driver windrvr6.sys version = 6.2.2.2. LPT base address = 0378h. ECP base address = FFFFFFFFh. Cable connection established. // *** BATCH CMD : identify Identifying chain contents ....done. ERROR:iMPACT:585 - A problem may exist in the hardware configuration. Check that the cable, scan chain, and power connections are intact, that the specified scan chain configuration matches the actual hardware, and that the power supply is adequate and delivering the correct voltage. Elapsed time = 0 sec. // *** BATCH CMD : identifyMPM Elapsed time = 0 sec. ERROR:iMPACT:589 - No devices on chain, can't assign file make: *** [download] Error 1 Done. The following is y bitgen.ut file -g ConfigRate:4 -g CclkPin:PULLUP -g TdoPin:PULLNONE -g M1Pin:PULLDOWN -g DonePin:PULLUP -g DriveDone:No -g StartUpClk:JtagCLK -g DONE_cycle:4 -g GTS_cycle:5 -g M0Pin:PULLUP -g M2Pin:PULLUP -g ProgPin:PULLUP -g TckPin:PULLUP -g TdiPin:PULLUP -g TmsPin:PULLUP -g DonePipe:No -g GWE_cycle:6 -g LCK_cycle:NoWait -g Security:NONE -m -g Persist:NoArticle: 93651
Hello all, I am new to this group, but it has already been a great resource.. thanks to all who post advice and suggestions! Good stuff. My current issue involves the Virtex-4 configuration pin called CCLK, which according to the V-4 Configuration Guide, "is different from previous Xilinx FPGAs" and requires parallel Thevenin termination. Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled up to Vcco and a 100 ohm pulled down to GND. Two questions: 1) Is this REALLY necessary, or just a good thing to have when configuring a device at higher CCLK frequencies? What if I just clock the bitstream at, say, 1 MHz? 2) What should I do since I want to have the option of using both Master Serial and Slave Serial? The CCLK signal will potentially terminate at either side, so where should the termination resistor(s) be placed? Thanks in advance, -mike.Article: 93652
Mike, Frequency does not matter. It is all about rise time. A fast rise time will create reflections. Reflections will create multiple edges. Multiple edges will cause double clocking. Double clocking will cause the device to be confused, and not configure. If you simulate the entire trace for CCLK, with the actual dimensions, and impedances, and loads and drivers (such as using Mentor's Hyperlynx SI tool), you will see what I am referring to. Also, if you simulate the run, you may find how to do this without a termination. It is so much simpler if we just tell you to do this as a best practice, rather than require you to simulate the trace, and design the net such that it has no reflections. Typically CCLK runs to many devices, so making such a net have no reflections is not possible without a parallel termination at the end of the run. Austin shogmic wrote: > Hello all, > > I am new to this group, but it has already been a great resource.. > thanks to all who post advice and suggestions! Good stuff. > > My current issue involves the Virtex-4 configuration pin called CCLK, > which according to the V-4 Configuration Guide, "is different from > previous Xilinx FPGAs" and requires parallel Thevenin termination. > Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled > up to Vcco and a 100 ohm pulled down to GND. Two questions: > > 1) Is this REALLY necessary, or just a good thing to have when > configuring a device at higher CCLK frequencies? What if I just clock > the bitstream at, say, 1 MHz? > > 2) What should I do since I want to have the option of using both > Master Serial and Slave Serial? The CCLK signal will potentially > terminate at either side, so where should the termination resistor(s) > be placed? > > Thanks in advance, > -mike. >Article: 93653
Hey all, I am trying to play around with Synplify and an EDK project I have already implemented solely in the EDK. I have flagged the "IMP_NETLIST = FALSE" in all the user IP in the project. Then I use the "Export to ProjNav" in the Tools menu. Opening the resulting "system.ise" project in the ISE tool works correctly. All the core vhdl and verilog "wrapper" files are added as sources correctly, but since the EDK did not synthesize the user IP, they all show up as "?" sources in the project. So just messing around, I pulled in the top level vhdl for one of my IP. This is the vhdl file that the import peripheral wizard made, and the one that I filled in correctly. Again, this project works fine in the EDK, so all files for all IP's are correct. Once I add that top vhdl file as a source, and the associated files for my IP, everything looks OK except for the opb_ipif source referenced in the vhdl file. It shows up as a "?" source. OK, so I add the source from the common libraries. So the opb_ipif looks OK, but it references sources that reference sources that reference sources, etc, etc, etc. I started adding all the sources it asked for. But then it gets down to some that are not even on the hard drive of my machine. They are nowhere to be found. So of course, the Synplicity errors out. Is there a way to do what I am trying to do? Basically, I want the EDK to synthesize the Xilinx IP and Synplicity to synthesize the user IP via the ISE. Then I guess I would pull the finalized bitstream back into the EDK for final compilation and download. I know I could probably black-box the user IP in the ISE first and then pull that into the EDK. But I am just messing around, evaluating what can and cannot be done using Synpilcity. It is a VERY expensive tool that we are trying to see is worth justifying. Thanks, TomArticle: 93654
I am currently developing a system where a user can configure an Spartan 3 FPGA from a Atmega 128(serial configuration). The system consists of FPGA, SRAM, Atmega128 and Dataflash. The system is connected as follows. Atmega128--->Dataflash, Atmega128--->FPGA, FPGA--->SRAM. Now I have run into this problem. As per my board layout the "DIN" signal of the Spartan 3 is connected to the SRAM where the conifiguration data is expected to be kept. The other serial configuration signals (INIT, PROG, CCLK, DONE) are available from the Atmega128. How would I got about configuring the FPGA. The SRAM is not connected to the Atmega128. My though process says that I need to have implemented an SRAM interface on the FPGA to access it, but then it is a catch-22 situation, as I need to configure the FPGA first. I do have a JTAG interface available to FPGA (which I implemented if such situations arose). But if I implement an SRAM interface on the FPGA (using JTAG), it will void the whole idea of configuring the FPGA from microcontroller. Any ideas? Can I configure the FPGA serially using either the D1, D2, D3 or D4 pins (which for some reason I connected to the Atmega 128)? Yaju Nagaonkar --- Electrical and Computer Engineering Brigham Young University Provo UT 84602 USAArticle: 93655
I have replaced the ISERDES with an inferred serial to parallel converter
and so I believe my problem was not with the ISERDES but with the input pin
not being able to see a sustained high. Do the differential LVDS inputs need
pullups? Below is the new code:
xclk_delay_process: process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_xclk_serial_bit(0) <= cam1_xclk;
cam1_xclk_serial_bit(1) <= cam1_xclk_serial_bit(0);
cam1_xclk_serial_bit(2) <= cam1_xclk_serial_bit(1);
cam1_xclk_serial_bit(3) <= cam1_xclk_serial_bit(2);
cam1_xclk_serial_bit(4) <= cam1_xclk_serial_bit(3);
cam1_xclk_serial_bit(5) <= cam1_xclk_serial_bit(4);
cam1_xclk_serial_bit(6) <= cam1_xclk_serial_bit(5);
if( cam1_xclk_serial_bit(2)='1' and cam1_xclk_serial_bit(1)='0' ) then
cam1_x0_en <= '1';
cam1_x1_en <= '1';
cam1_x2_en <= '1';
cam1_x3_en <= '1';
else
cam1_x0_en <= '0';
cam1_x1_en <= '0';
cam1_x2_en <= '0';
cam1_x3_en <= '0';
end if;
end if;
end process;
--------------------------------------------------------------------------
-- Camera Link Deserializers
--
-- Each of the four serial streams X0 X1 X2 and X3
-- have a pair of differential inputs _n and _p
-- attached to the gpio_exp_hdr2 (General Purpose Input Output Header 2 )
-- that must be reconciled with an IBUFDS (Input BUFfer Differential Swing)
cam1_x0_ibufd_inst : IBUFDS
port map (
O => cam1_x0,
I => cam1_in(1),
IB => cam1_in(0) );
cam1_x0_serial_process : process(cam1_clk7x)
begin
if( cam1_clk7x'event and cam1_clk7x='1' ) then
cam1_x0_serial_bit(0) <= cam1_x0;
cam1_x0_serial_bit(1) <= cam1_x0_serial_bit(0);
cam1_x0_serial_bit(2) <= cam1_x0_serial_bit(1);
cam1_x0_serial_bit(3) <= cam1_x0_serial_bit(2);
cam1_x0_serial_bit(4) <= cam1_x0_serial_bit(3);
cam1_x0_serial_bit(5) <= cam1_x0_serial_bit(4);
cam1_x0_serial_bit(6) <= cam1_x0_serial_bit(5);
if( cam1_x0_en='1' ) then
cam1_x0_bit(0) <= cam1_x0_serial_bit(0);
cam1_x0_bit(1) <= cam1_x0_serial_bit(1);
cam1_x0_bit(2) <= cam1_x0_serial_bit(2);
cam1_x0_bit(3) <= cam1_x0_serial_bit(3);
cam1_x0_bit(4) <= cam1_x0_serial_bit(4);
cam1_x0_bit(5) <= cam1_x0_serial_bit(5);
cam1_x0_bit(6) <= cam1_x0_serial_bit(6);
end if;
end if;
end process;
Article: 93656I would suggest doing whatever they say. I have had trouble designing a Spartan board downloading at 5Mhz. Adding the resistors helped quite a bit but still I have some flyby taps at about 10mm that still give me trouble. It also helps if you can turn off the other clocks during your download periods. Don't know about your master/slave problem. Perhaps you can add a series resistance and get by with that as, as you say, you want to clock at 1 MHz. "shogmic" <shogmic@iit.edu> wrote in message news:1135721828.251908.18690@g47g2000cwa.googlegroups.com... > Hello all, > > I am new to this group, but it has already been a great resource.. > thanks to all who post advice and suggestions! Good stuff. > > My current issue involves the Virtex-4 configuration pin called CCLK, > which according to the V-4 Configuration Guide, "is different from > previous Xilinx FPGAs" and requires parallel Thevenin termination. > Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled > up to Vcco and a 100 ohm pulled down to GND. Two questions: > > 1) Is this REALLY necessary, or just a good thing to have when > configuring a device at higher CCLK frequencies? What if I just clock > the bitstream at, say, 1 MHz? > > 2) What should I do since I want to have the option of using both > Master Serial and Slave Serial? The CCLK signal will potentially > terminate at either side, so where should the termination resistor(s) > be placed? > > Thanks in advance, > -mike. >Article: 93657
According to the front page of xilinx's site but not yet in the web shop. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-DK With double the amounts of ram and flash than origonally announced. Now if only xilinx sold digilentincs addon cards so could get some decent shipping charges. AlexArticle: 93658
Hi all, I have a Altera Cyclone chip which is input by a 50MHz osc. I want to use this 50MHz clock directly without PLL. This means I just use a clk as input and assign the PIN GCLK to clk. Is it OK? Thanks in advance. ABAIArticle: 93659
No problem.. Using PLL is optional.. If you have a doubt yet, use PLL with 1x, 1 div. setting. (P.S In subject.. with-> without.. Am I right?)Article: 93660
Hi. I have interest with VME bus. Google teach me that silicore made VME core. But I can't connect silicore website. What happen? Can I get VME core? Thanks!Article: 93661
Antti - Yes, I've found several serious bugs so far, hence the desire for a testbench. If I can't find anything and what I write is not too ugly, I'll probably post it. John ProvidenzaArticle: 93662
As Austin wrote, the frequency does not matter, the rise/fll time does, and it is really not under your control. So, make sure that the CCLK distribution is one serial "worm". not a tree with many branches. then terminate it at the very end. Your enemy are the reflections that result in double-triggering. If everything else fails, you can load the clock with 100 pF, but that is just a dirty emergency repair. Another dirty trick is to put 10 Ohm in series with the CCLK driver, and then decouple the downstream side of that resistor with 100 pF. Austin would never recommend this, but I sense your desperation... Peter Alfke shogmic wrote: > Hello all, > > I am new to this group, but it has already been a great resource.. > thanks to all who post advice and suggestions! Good stuff. > > My current issue involves the Virtex-4 configuration pin called CCLK, > which according to the V-4 Configuration Guide, "is different from > previous Xilinx FPGAs" and requires parallel Thevenin termination. > Basically, a 50 ohm resistor pulled up to Vcco/2, OR a 100 ohm pulled > up to Vcco and a 100 ohm pulled down to GND. Two questions: > > 1) Is this REALLY necessary, or just a good thing to have when > configuring a device at higher CCLK frequencies? What if I just clock > the bitstream at, say, 1 MHz? > > 2) What should I do since I want to have the option of using both > Master Serial and Slave Serial? The CCLK signal will potentially > terminate at either side, so where should the termination resistor(s) > be placed? > > Thanks in advance, > -mike.Article: 93663
My CL work has always been done within Altera parts. I use their PLL and timing constraints to get the timing I need to pick off the data correctly. One thing that has always helped me in debuging this type of design is to, if possible, turn off the video while still allowing the control signals to go through. Perhaps you have the abilty to generate a test pattern. Setting the test pattern to all 0's will enable you not to confuse the control bits with a video signal. And then I usually pick lsync and tune the timing until it is coming out in the correct position. Do you have the ability to look at the parallel data: perhaps you can send the parallel data to test points? Have you verified that the termination resistors are getting turned on? Or do you have on-board discrete resistors? My experience with CL problems has always been FPGA timing. What is your clock speed? I've run with 66MHz clocks (x7 462Mbps) and one must be very careful not to have too much skew between the high speed clock and your input shift registers. Rob "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:11r1sjkjnoccp44@corp.supernews.com... > Hi Rob, > > Thanks for the moral support. > > There is a jumper to make these bank 7 inputs 2.5V instead of 3.3V which I > switched. No effect. > > I ran the inputs into a second camera jack available on my daughter board, > to see if I had some solder problems on the first jack. That resulted in > the same issues. > > My scope is old so I am just looking at the tiniest wiggles but again they > seem to be OK. In fact I can see the LVAL in the original signal making it > wiggle higher than the rest of the signal. > > Are you using IDELAY to control the timing? > > Brad > > > "Rob" <robnstef@frontiernet.net> wrote in message > news:1Y_rf.430$qg.31@news02.roc.ny... >>I know on Altera parts you have to tell the tool to turn on the on-chip >>termination resistors: it may be the same with Xilinx. Also, I know on >>V2PRO parts the banks running differenital I/O must be operated with a >>2.5V VCCIO. >> >> Also, I would look at the inputs at the connector to make sure that they >> are acting as expected. If you don't have a differential probe you can >> get a reasonable look with a single ended one. This is just to make sure >> that you're not chasing the wrong problem. >> >> I've done many designs with Camera Link so let me know if you need >> anything else. >> >> Let us know what you find. >> >> >> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message >> news:11r0jedsghr3me0@corp.supernews.com... >>> Hello, >>> >>> Having trouble with some LVDS signals coming from a Camera Link >>> interface. I expect to see from steady signals coming from this line >>> camera. DVAL=1. But it's not there. And the LVAL, line valid, only comes >>> on for maybe one clock, and I expect it to come on for 2K clocks. >>> >>> I am using IBUFDS as inputs. The UCF file loc the pins but that is all. >>> Do I need something more to drop the 100 ohm termination resitance? >>> >>> Brad Smallridge >>> aivision.com >>> >>> >>> >>> >> >> > >Article: 93664
"Peter Alfke" <alfke@sbcglobal.net> wrote in message > If everything else fails, you can load the clock with 100 pF, but that > is just a dirty emergency repair. Wow, I'm so relieved to see that someone else has done this. The real trick, however, is to make sure that this hack works long enough, in production, so that your stock options are vested, exercised, and sold. I guess it's safe for me to come out-of-the-closet, now. Thanks for your honesty, Peter. BobArticle: 93665
I've never needed to pull-up LVDS signals that were being driven. I've driven as far as 10feet, too. Remember, the voltage genereated is a result of the current passing through the termination resistor. Are you saying that the inferred serial to parallel code works and the ISERDES doesn't? Do you have both the negative and the postive signals called out in your designs UCF file? "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:11r3s94o15o8q6a@corp.supernews.com... >I have replaced the ISERDES with an inferred serial to parallel converter >and so I believe my problem was not with the ISERDES but with the input pin >not being able to see a sustained high. Do the differential LVDS inputs >need pullups? Below is the new code: > > xclk_delay_process: process(cam1_clk7x) > begin > if( cam1_clk7x'event and cam1_clk7x='1' ) then > cam1_xclk_serial_bit(0) <= cam1_xclk; > cam1_xclk_serial_bit(1) <= cam1_xclk_serial_bit(0); > cam1_xclk_serial_bit(2) <= cam1_xclk_serial_bit(1); > cam1_xclk_serial_bit(3) <= cam1_xclk_serial_bit(2); > cam1_xclk_serial_bit(4) <= cam1_xclk_serial_bit(3); > cam1_xclk_serial_bit(5) <= cam1_xclk_serial_bit(4); > cam1_xclk_serial_bit(6) <= cam1_xclk_serial_bit(5); > if( cam1_xclk_serial_bit(2)='1' and cam1_xclk_serial_bit(1)='0' ) then > cam1_x0_en <= '1'; > cam1_x1_en <= '1'; > cam1_x2_en <= '1'; > cam1_x3_en <= '1'; > else > cam1_x0_en <= '0'; > cam1_x1_en <= '0'; > cam1_x2_en <= '0'; > cam1_x3_en <= '0'; > end if; > end if; > end process; > > > -------------------------------------------------------------------------- > -- Camera Link Deserializers > -- > -- Each of the four serial streams X0 X1 X2 and X3 > -- have a pair of differential inputs _n and _p > -- attached to the gpio_exp_hdr2 (General Purpose Input Output Header 2 ) > -- that must be reconciled with an IBUFDS (Input BUFfer Differential > Swing) > > cam1_x0_ibufd_inst : IBUFDS > port map ( > O => cam1_x0, > I => cam1_in(1), > IB => cam1_in(0) ); > > cam1_x0_serial_process : process(cam1_clk7x) > begin > if( cam1_clk7x'event and cam1_clk7x='1' ) then > cam1_x0_serial_bit(0) <= cam1_x0; > cam1_x0_serial_bit(1) <= cam1_x0_serial_bit(0); > cam1_x0_serial_bit(2) <= cam1_x0_serial_bit(1); > cam1_x0_serial_bit(3) <= cam1_x0_serial_bit(2); > cam1_x0_serial_bit(4) <= cam1_x0_serial_bit(3); > cam1_x0_serial_bit(5) <= cam1_x0_serial_bit(4); > cam1_x0_serial_bit(6) <= cam1_x0_serial_bit(5); > if( cam1_x0_en='1' ) then > cam1_x0_bit(0) <= cam1_x0_serial_bit(0); > cam1_x0_bit(1) <= cam1_x0_serial_bit(1); > cam1_x0_bit(2) <= cam1_x0_serial_bit(2); > cam1_x0_bit(3) <= cam1_x0_serial_bit(3); > cam1_x0_bit(4) <= cam1_x0_serial_bit(4); > cam1_x0_bit(5) <= cam1_x0_serial_bit(5); > cam1_x0_bit(6) <= cam1_x0_serial_bit(6); > end if; > end if; > end process; > >Article: 93666
Just make sure that you tie the osc to one of the clock pins that drives into the global clock network. "Binary" <binary.chen@gmail.com> wrote in message news:1135735920.634199.74660@g14g2000cwa.googlegroups.com... > Hi all, > > I have a Altera Cyclone chip which is input by a 50MHz osc. I want to > use this 50MHz clock directly without PLL. This means I just use a clk > as input and assign the PIN GCLK to clk. > > Is it OK? > > Thanks in advance. > > ABAI >Article: 93667
Bob wrote: >> I guess it's safe for me to come out-of-the-closet, now. Thanks for your > honesty, Peter. > My suggestion is like a band-aid or an aspirin. Perhaps effective, but really just camouflaging the true problem. The true problem is improper lay-out or wrong termination, generating double-pulses from the fast transitions. The CCLK frequency itself is irrelevant. Peter AlfkeArticle: 93668
"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1135743326.126840.299580@g47g2000cwa.googlegroups.com... > > Bob wrote: >>> I guess it's safe for me to come out-of-the-closet, now. Thanks for your >> honesty, Peter. >> > My suggestion is like a band-aid or an aspirin. > Perhaps effective, but really just camouflaging the true problem. > The true problem is improper lay-out or wrong termination, generating > double-pulses from the fast transitions. The CCLK frequency itself is > irrelevant. > Peter Alfke > Yep, that's a common misconception that it's the frequency that causes reflections. We did a board that had a "double-pulse" problem on a 1MHz JTAG test port (one TCK buffer output driving multiple JTAG ports). Now, we distribute TCK like any other clock, and source terminate each buffer output. It all seems so easy, now, but it's taken a couple of 'ahshits' to get there. BobArticle: 93669
I think I can find way to avoid the existed bugs, but I do not know whether there are any other bugs existed in step 2. So thank you share your exp on SX55 with me. Thanks, Engine "Ray Andraka" wrote: > Engine wrote: > >> A friend send me a document link. >> http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf >> >> He suggest we do not select Virtex4 in our projects. >> >> I am not sure the real meaning of this document. >> >> Does it mean that there are three bugs in the step 1 Virtex4 LX/SX? >> Why do not call the Step 2 LX/SX as the mass production LX/SX? >> Are there still bugs in step 2 LX/SX? >> Whether step 3 LX/SX will be relased later? >> Why FX is in step 0 now, what's the defination of step 0? >> >> Please help me! >> >> If it is ture, I would like to use the old VirtexII or Stratix on my >> projects. >> >> Thanks, >> Engine >> >> >> >> >> > > Think of the stepping number as service packs for the silicon. The higher > stepping numbers generally reflect silicon revisions to correct > deficiencies in earlier silicon. There aren't really any show-stopper > bugs in the V4 silicon, so I wouldn't discard a V4 solution jsut because > someone suggested you didn't use the parts. > > Step 0 is the first silicon, which is/was sold as the engineering samples. > > The NBTI problem mentioned in the link you posted turns out to be a > non-problem for real world designs. It does degrade DCM performance if > the DCMs are not operated according to the constraints listed, but the DCM > is so much faster than what is required to support the fabric, that the > degradation does not slow them enough to affect real-world designs. IMHO, > Xilinx did the right thing with regards to disseminating info about the > NBTI problem so that customers could work with all the info known at the > time rather than leaving the customer to potentially discovering a problem > on their own later (unlike the handling of the FIFO16 issue). > > The Virtex4 does have significant advantages over the earlier families. As > with most silicon rollouts of this complexity, there are some fairly minor > bugs in the design that will be worked out over time. The only one I am > aware of that is a show stopper is the MGT's in the FX line. If that > doesn't affect your design plans, there is no reason I can see to avoid > the V4 line. I've got a couple major V4SX55 designs working satisfactorly > in the lab now, and overall I am happy with the device.Article: 93670
Bob wrote: > We did a board that had a "double-pulse" problem on a 1MHz JTAG test port > (one TCK buffer output driving multiple JTAG ports). Now, we distribute TCK > like any other clock, and source terminate each buffer output. > Source termination is great if you have one source driving a single destination. Just put a series-terminating resistor right at the driver, and let the isgnal bounce up to full amplitude at the openended destination. But never (never!) use source termination when you are drving multiple detinations along a clock trace. The half-amplitude signal travelling along the line will cause you lots of grief. Peter AlfkeArticle: 93671
Hi All, Has anyone made some experiences with fpga and drm. I'm looking for informations and papers to set up my own project based on the algorithms of the DREAM-Project. Thanx SBArticle: 93672
Hi all.
I tried to build a project in DK.
Compiling is OK but i think i have a problem at the linkage.
The output shows this error:
"No simulation command line option specified ('-cl' option)"
The code is very simple:
set clock=external ;
void main(void)
{
int 4 result;
int 4 num;
result=5;
num=result;
}
Anyone can help me?
Thanks a lot
Article: 93673
HI
i'm working on a project where I get the following warning message:
-----------------------------------+---------------------------------------------+-------+
Clock Signal | Clock buffer(FF name) |
Load |
-----------------------------------+---------------------------------------------+-------+
CLK_4MHZ1(CLK_4MHZ1:O) |
BUFG(*)(I_Sensor_Interface/s_Clock_Count_11)| 32 |
CLK | I_Clock/DCM_INST:CLKFX
| 3 |
-----------------------------------+---------------------------------------------+-------+
(*) This 1 clock signal(s) are generated by combinatorial logic,
and XST is not able to identify which are the primary clock signals.
Please use the CLOCK_SIGNAL constraint to specify the clock signal(s)
generated by combinatorial logic.
How can I tell Ise what my primary clock signal is or what do i have to
do?
Thanks
Urban
Article: 93674Hi Bob, The answer is to do as Austin says and simulate the thing. No 'ahshits' or bodged on caps needed. The Mentor marketing hype is pretty close when it says that the tool pays for itself in just 1 or 2 PCB respins because the SI is bad first time. It also makes sure that your design isn't marginal. Two 'ahshits' may have got your design working, but will it survive the next rev. of the silicon because it only just worked? BTW, another misconception is that buffering always fixes the problem. Most buffers are very good at driving lines with faster rise times than the original driver. This makes the problem even worse. Best, Syms. p.s. I chuckled at Brad's "I would suggest doing whatever they (Xilinx) say."! I'd suggest maybe using their designs as a start, then think about your own application. Remember, Xilinx has to suggest things that will work for a multitude of designs. This may not be the most efficient for your design. In fact I'd question whether a 'one size fits all' is even possible at all for some situations. "Bob" <nimby1_notspamm_@earthlink.net> wrote in message news:7Bpsf.3534$R84.1704@newsread2.news.pas.earthlink.net... > > Yep, that's a common misconception that it's the frequency that causes > reflections. > > We did a board that had a "double-pulse" problem on a 1MHz JTAG test port > (one TCK buffer output driving multiple JTAG ports). Now, we distribute > TCK like any other clock, and source terminate each buffer output. > > It all seems so easy, now, but it's taken a couple of 'ahshits' to get > there.
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