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
"John_H" <newsgroup@johnhandwork.com> wrote in message news:a0c51d7c-707e-4180-b888-67dd7f42865c@a75g2000hsb.googlegroups.com... > > You say your input is LVDCI_25 and unterminated. To me, this is > conflicting information. Isn't the LVDCI_25 explicitly internally > terminated by the DCI termination scheme applied to that pad? I know > what DCI is capable of but despite being "ready" for DCI in a design > or two, I've never used it so I don't have the practical experience of > configuring those input terminations. > > Another question for the system if the DCI input termination is > present: how much drive is required by the PHY and is it happy to > deliver that power? > > It's certainly a quandry. > > - John_H > John - The LVDCI_25 inputs are normal unterminated LVCMOS inputs. It's the outputs that have internal DCI series termination. RobArticle: 129126
My aoplogies. The point of my email was not to generate vague ideas, speculations and misconceptions. It was honestly meant as a brain storming tool to figure out what was wrong and inform you that the issue was not with the design process. Again I apologies if it came out any other way. "Jürgen Böhm" <jboehm@gmx.net> wrote in message news:fp2avs$cc$00$1@news.t-online.com... > Dwayne Dilbeck wrote: >> Timing issues are not going to effect the ability to program. Timing >> issues >> will cause you to recieve values that you are not expecting inside the >> design. >> >> Are you using the USB or Parrallel cable? A programming error occurs >> becuase the transmision to the FPGA is corrupted. You could have a bad >> board where the JTAG header isn't connected well. That would affect >> transmision and make it sparatic. You could have a faulty programming >> cable >> that could make it sparatic. Your USB or Parrallel ports could be sub >> standard and not sufficient to the task. > > I use the so called "Parallel Cable 3" (Digilent JTAG3) (connected to > the so called J7 header of the Starter Kit). It can be found as JTAG3 > cable on the page > > http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable > > As it is advertised as a "low-cost-solution", one could speculate > about the cable as the source of the problem - but maybe another reason > is, that I left the cable plugged into the board for months and maybe > somehow oxidation crept in. > >> >> Try checking those areas. Timing in your desgin will not effect your >> ability to down load. >> > > Thanks for this information - it is always a bit difficult for an > FPGA hobbyist without academic background in electrical engineering not > to fall prey to vague ideas, speculations and misconceptions. > > > Jürgen > > > > > -- > Jürgen Böhm www.aviduratas.de > "At a time when so many scholars in the world are calculating, is it not > desirable that some, who can, dream ?" R. ThomArticle: 129127
austin schrieb: > Philip, > > Let me check. > > Might be a bug. > > Austin It seems that, for many cores in EDK 9.2i, the VirtexII and VirtexII-Pro are marked as not supported device families. This is true for the most up to date core revisions (like MB 7.0), the older revisions still support V2 and V2P. Are they supported again in EDK 10.x? Or does Xilinx drop support for "old" device families to sell more of the more recent ones? -MarkusArticle: 129128
Dwayne Dilbeck wrote: > My aoplogies. The point of my email was not to generate vague ideas, > speculations and misconceptions. It was honestly meant as a brain storming > tool to figure out what was wrong and inform you that the issue was not with > the design process. > > Again I apologies if it came out any other way. > No, no, it came out quite right - with vague ideas, speculations and misconceptions I meant my mind-state before getting your (and the others) answer - now I see clearer at this point, thanks again to you and to the others who took the time to answer my question. Jürgen -- Jürgen Böhm www.aviduratas.de "At a time when so many scholars in the world are calculating, is it not desirable that some, who can, dream ?" R. ThomArticle: 129129
Hi I am laying out a board for a Virtex 4 FX20 in a FF672 package. Now would it be ok if I connected some of the NC pins for this device such as ground and VCCO so that I could use an FX40 or FX60 if I wanted? Would any damage be done to the FX20 by connecting to these NC pins? Thanks JonArticle: 129130
On Feb 14, 12:50 pm, rossalbi <rossa...@hotmail.com> wrote: > hi, i have writen a pice of code which should impliment a value on > the > LEDs of my FPGA development board as the signal 'count' increases. > However it is going strait to the ' when others => LEDs <= > "00000000"; > ' value. > > any help would be much appreciated... > > -- Declare signals > signal CLK : std_logic; > signal RST : std_logic; > signal Count : std_logic_vector(21 downto 0); > signal LEDs : std_logic_vector(7 downto 0); > signal LEDVal : std_logic_vector(7 downto 0); > signal Dir : std_logic; > > begin > > -- Tie unused signals > User_Signals <= "ZZZZZZZZ"; > IO_CLK_N <= 'Z'; > IO_CLK_P <= 'Z'; > IO <= (0=>LEDs(0), 1=>LEDs(3), 41=>LEDs(4), 42=>LEDs(1), > 43=>LEDs(4), > 44=>LEDs(5), 45=>LEDs(2), 46=>LEDs(7), > others => 'Z'); > > -- Clock divider > process (CLK, RST) > begin > if (RST='1') then > Count <= (others=>'0'); > elsif (CLK'event and CLK='1') then > Count <= Count + 1; > end if; > end process; > > process (CLK, RST) > begin > > case Count is > when "0000000000000000000000" => LEDs <= "00000001"; > when "0000000000000000000001" => LEDs <= "00000010"; > when "0000000000000000000010" => LEDs <= "00000100"; > when "0000000000000000000011" => LEDs <= "00001000"; > when "0000000000000000000100" => LEDs <= "00001001"; > . > . > when "0000000000000001111110" => LEDs <= "01000000"; > when "0000000000000001111111" => LEDs <= "10000000"; > > when others => LEDs <= "00000000"; > end case; > > end process; You just need "Count" in the process sensitivity list. If the clock is faster than a few tens of Hz all the LEDs will just glow at varying levels. Unless "Count" is used elsewhere it only needs to be about 3 bits long. If the clock is a reasonable speed, then you might fair better using the upper bits of count as these will toggle slower. You can work out how fast the bits toggle using maths.Article: 129131
On Feb 14, 10:58=A0am, rabbiaqa...@yahoo.com wrote: > =A0i want information about fpga boards. for my application i required a > fpga board with pcie interface and 10 Giga bit /s interface . i have > searched a lot but i didn't find anyone. how can i find it. > another question i want to ask is i am studying the manual of startix > II GX PCI express development board .does it have 10 Gig interface. it > has HSMC port. to use this card which daughter card will be used.but > remember i need 10 Gig interface. Check this http://www.xilinx.com/publications/matrix/matrix_XDev_boards.pdfArticle: 129132
On Feb 13, 7:24=A0pm, tullio <tullio.gra...@gmail.com> wrote: > I am using for the first time a Xilinx RocketIO module (I have years > of FPGA experience though); normally I prefer to explicitly write on > my code all the instatiations. > Manual UG196 says:" The RocketIO GTP Transceiver Wizard is the > preferred tool to generate a wrapper to instantiate a GTP_DUAL > primitive." > > Any experience and advice about coding vs wizard in the case of > RocketIO ? > > My application requires to use the GTP for a simple but non-standard > protocol (8b/10b with a custom packet). > > Regards, > > =A0 Tullio Grassi > =A0 Fermilab Its not just about instantiation. More than that, choosing the right values for the parameters as GTP has large number of parameters. GTP wizard helps you to setup the required values for parameters based on applications. Eg. SATA, PCIe. However, from my experience - Some parameter's default values from GTP wizard may not work good for you. Need a code chage in this case.Article: 129133
J=FCrgen wrote: > > Mostly then, "Success" is signaled, but, seemingly randomly, "Failed" > is returned as a big red warning sign. In these cases I usually reset to > the PROM-configuration and try the cycle beginning with Init-Chain above > again, sometimes I shorten it to just doing the "Program" with > right-click-select. After a couple of tries, this seemed to work at all > times. > Try this: change the J8 configuration mode jumpers to "JTAG" ( off:on:off ) change the JP1 bitstream readback jumper setting to "disable" see also these old posts & surrounding threads http://groups.google.com/group/comp.arch.fpga/msg/8b2144041295cd24 http://groups.google.com/group/comp.arch.fpga/msg/4b42492726538104 BrianArticle: 129134
DONT look for incorrect code !
write correct code .
It should have occurred to you the
s/w you bought could never create
good bug free code !
The authors had no intention to sell
you a better way to generate code !
There is only one way to write good
code , write it all , yourself .
You begin by sending serial ( rs232 or SPI)
strings to ARM , running them .
The ones that dont crash and light up the
red , green , and blue LEDs in the right
order are your "tutorial" .
Learn to create code that assembles
and stores short Forth primatives in a
dictionary , so you can use these primatives
to help you create higher level sequences
of code .
Chuck Moore did this in the 70's , in Tucson
to put many programmers out of a job .
He created Forth ( the simplist method to
program).
You will save many months of "learning" curve
by not reading thick s/w manuals , you can
charcterize the ARM yourself , with Forth , in
minutes , and save the results to the Forth
dictionary , to aide others .
There is no future , for M$ , C , Linux ,
and the PC ...
why not study modern techniques and
burn your s/w "Books" ?
All critical s/w is written
NOT using C , and
NOT using available assemblers
Not using Linux ,
Not using Intel , AMD cpu's
...........
More than 2.5 billion A.R.M cpu's
on this earth , the Thumb-2 instruction
set is used more than the 32 bit instructions
cause its faster !
The ST electronics company makes
ST-710-FZ2 ARM 7 , has 144 pins
6 mhz I/O ,
internal 65 K SRAM and huge flash .
It will be configured with 32MB PSRAM .
and a non-prop USB 480 mb/s serial
port ( "Hi-Speed... Run Length Limited h/w).
PC is dead ,
ARM-BC ( business computer follows)
KC7CC
Article: 129135"werty" <werty@swissinfo.org> wrote in message news:ca335791-2913-42aa-90e8-c2655e0128fb@u10g2000prn.googlegroups.com... > > DONT look for incorrect code ! > > > write correct code . > > > It should have occurred to you the <snip> etc. etc. Is it me?? Dave.Article: 129136
Vijayan wrote: > Hi all, > > I am using Virtex 4 FPGA (XC4VFX100) in our application. In this, we > find some erratic behaiour of FPGA. > > Whenever the bit file is loaded into the FPGA, there is a drop in core > voltage(power module getting shutdown).Bit file gives such random > behaviour uses particular three banks for its logic. Here we thought > like this, it may be due to any internal damage in FPGA IOBs around > that three banks. > > Here is the few points added, > > * We tried with a bit file that has high logic utilization (logic is > not on that faulty banks. it uses other banks). It works fine. > * Also we tried some other bit files with low logic utilization using > that banks is working properly (power won't disturbed). > * Whatever signals from that faulty banks are not shorted with VCC/ > GND. We probed it. > * Good core voltage power solution. > > Pls suggest me the solution to identify the exact source of that > behaviour. > > Regards, > Vijayan Have you checked that the I/O on the faulty banks is not in contention ie pins driving against each other. I know you say there are no shorts to VCC/GND but could there be I/O shorts on the faulty banks ? Good luck -- Dunstan ByteSnap Design Ltd, Web: www.bytesnap.co.ukArticle: 129137
Markus, I am trying to find out what the story is. One point is that "if" a new release of uBlaze supported all older products, that would actually be a tremendous amount of work (of potentially very little value). This might be the reality: the latest and greatest uBlaze is really just for the latest and greatest silicon. If you need an older uBlaze for an older part, they are all still archived. The code is still backward compatible, however. That verification is extremely valuable, so there is a reason to perform that step on all new releases. So, until I get the 'official' word, I have to wait and see. AustinArticle: 129138
Jon, NC is just that: no connect. We reserve the right to do anything we might need to do with these pins, so just follow the rules: do not connect them to anything at all. AustinArticle: 129139
I have written a process to generate sine wave. I am getting a distorted wave and not a pure sine wave. I am not sure if this has anything to do with the simulator. two : process variable phase_temp,result : real; constant scale : real := 2.0*real(bw); begin phase_temp := phase_sin; --phase_sin; l1 : for i in 1 to samples_sin loop --number_of_samples loop result := scale*(amp_sin*(sin(frq_sin + phase_temp))); sine_real <= (amp_sin*(sin(frq_sin + phase_temp))); sinWave <= toSigned(result,bw); phase_temp := phase_temp+incr_sin; wait for 5 ns; end loop l1; end process two; generic value : phase_sin : real := 0.0; samples_sin : integer := 1000; incr_sin : real := 1.0; frq_sin : real := 1000.0; I dont see the frequency of the wave change if the frq_sin is changed. Same happens when samples_sin is changed. I am not sure what is going wrong. Please helpArticle: 129140
Lets assume the configuration vector is 7:0. The target vector will be also 7:0 (naturally) The key to solving this is to observe for each configuration bit how many "1"s are to its left and "0"s to its right. For example: if we start from the left (bit 7) and move along to the right (bit 0) on the configuration vector. we see that the first 1 we can encounter can be only in places 7,6,5,4 ,3 - one of these should be muxed to location 7 (MSB) of the target vector. The second "1" we encounter can ONLY be in position 6,5,4,3,2 and one of those should be muxed to target location 6. continue like this and you will see that it is basically a set of 5:1 muxes (or 4:1 + a 2:1 mux) for each target location. This is for the 4 high locations 7 to 4 in the target. for locations 3 to 0 you have to look at the first "0" but approaching from the RIGHT this time. you will also get 4 5:1 muxes for the logic. the control logic is easily generated by decoding the place of the first "1", then the second "1" etc, etc. (and analogously for the "0"s of course). There are many optimizations that can be made along the way but this approach is easiest to understand (for me) - it is also by far cheaper than the huge LUT that was suggested before. This is really a nice problem, I am actually considering posting about it on my blog at http://asicdigitaldesign.wordpress.com cheers, NirArticle: 129141
I am looking at getting a new PC for doing FPGA development. I mostly use the altera tools and aldec active HDL. I was wondering if anyone had any thoughts or comments on optimal PC configurations for this. What affects synthesis time, place and route time - Cache size? SDRAM speed/bandwidth , amount of total SDRAM (2 vs 4 vs 8 GB main memory). Do 32 vs 64 bit architectures make any difference at all? What about CPU clock speed - Is the price delta from a 2.0 GHz machine to a 3.2 GHz machine really worth it in terms of reducing compile times? What about multicore? Is it possible to have too many cores? is there an optimal number in terms of bang for the buck? Are there any advantages between the various Intel or AMD chip architectures? I know similar questions have been posed before, but I thought it would be good to revisit this, now that we are seeing the PC market flooded with new multicore processors, and EDA tool vendors starting to parallelize their algorithms to take advantage of the new CPUs.Article: 129142
Philip, So, here is the answer: "Bottom line - not a bug, no intention of dropping V2Pro support, all better in 10.1." Turns out, we just haven't done all the work needed to support V7.0 in V2Pro in 9.x, and that work is scheduled for the next release. The "worst case scenario" of 'not supported' is not the case, and I am impressed with the work these folks do to provide such a degree of support. AustinArticle: 129143
>NC is just that: no connect. We reserve the right to do anything we >might need to do with these pins, so just follow the rules: do not >connect them to anything at all. There was a time when you could rely on a label like that...when a door marked PRIVATE would be respected...when NC meant "NC"...when people didn't ask WHO SAYS I CAN'T PRESS THIS BUTTON?? But hey, it's 2008. MikeArticle: 129144
>> DONT look for incorrect code ! >> write correct code . >> It should have occurred to you the > ><snip> > >etc. etc. >Is it me?? No, it's him - like one of those Japanese soldiers holed up on an island, still waiting for orders long after the war was lost. MikeArticle: 129145
On Feb 15, 9:09=A0am, MikeShepherd...@btinternet.com wrote: > >NC is just that: no connect. =A0We reserve the right to do anything we > >might need to do with these pins, so just follow the rules: do not > >connect them to anything at all. > > There was a time when you could rely on a label like that...when a > door marked PRIVATE would be respected...when NC meant "NC"...when > people didn't ask WHO SAYS I CAN'T PRESS THIS BUTTON?? > > But hey, it's 2008. > > Mike It depends on the interpretation of NC. (Beware of the hidden meaning of Aronyms) Some users mistakenly think it means: Xilinx has Not Connected anything to this pin, so I can connect anything I want to it. The more correct meaning is: Xilinx asks you Not to Connect anything to this pin, because it might already be used for mysterious undocumented purposes. This latter meaning goes back to vacuum tube (valve) sockets in the 'fourties. Peter AlfkeArticle: 129146
On Feb 15, 8:11=A0am, FPGA <FPGA.unkn...@gmail.com> wrote: > I have written a process to generate sine wave. I am getting a > distorted wave and not a pure sine wave. I am not sure if this has > anything to do with the simulator. > > two : process > variable phase_temp,result : real; > constant scale : real :=3D 2.0*real(bw); > begin > =A0 =A0 =A0 =A0 phase_temp :=3D phase_sin; --phase_sin; > =A0 =A0 =A0 =A0 l1 : for i in 1 to samples_sin loop --number_of_samples lo= op > =A0 =A0 =A0 =A0 result :=3D scale*(amp_sin*(sin(frq_sin + phase_temp))); > =A0 =A0 =A0 =A0 sine_real <=3D (amp_sin*(sin(frq_sin + phase_temp))); > =A0 =A0 =A0 =A0 sinWave <=3D toSigned(result,bw); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 phase_temp :=3D phase_temp+incr_sin; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wait for 5 ns; > =A0 =A0 =A0 =A0 end loop l1; > > end process two; > > generic value : =A0 phase_sin : real :=3D 0.0; =A0 samples_sin : integer := =3D > 1000; =A0 incr_sin : real :=3D 1.0; > =A0 frq_sin : real :=3D 1000.0; > > I dont see the frequency of the wave change if the frq_sin is changed. > Same happens when samples_sin is changed. I am not sure what is going > wrong. Please help Your frq_sin value is actually just a phase offset. There is no time associated with this constant to feed the sin(). The phase_temp, on the other hand, is effectively t*incr_sin where t is a cycle count. To see the frequency change, change the incr_sin value instead. In what way is your sine distorted? - John_HArticle: 129147
On Feb 15, 8:40=A0am, Nir Dahan <write2...@googlemail.com> wrote: > Lets assume the configuration vector is 7:0. > The target vector will be also 7:0 (naturally) > > The key to solving this is to observe for each configuration bit how > many "1"s are to its left and "0"s to its right. > For example: > =A0if we start from the left (bit 7) and move along to the right (bit 0) > on the configuration vector. we see that the first 1 we can encounter > can be only in places 7,6,5,4 ,3 - one of these should be muxed to > location 7 (MSB) of the target vector. > The second "1" we encounter can ONLY be in position 6,5,4,3,2 and one > of those should be muxed to target location 6. > continue like this and you will see that it is basically a set of 5:1 > muxes (or 4:1 + a 2:1 mux) for each target location. > This is for the 4 high locations 7 to 4 in the target. > for locations 3 to 0 you have to look at the first "0" but approaching > from the RIGHT this time. > you will also get 4 5:1 muxes for the logic. > > the control logic is easily generated by decoding the place of the > first "1", then the second "1" etc, etc. (and analogously for the "0"s > of course). > > There are many optimizations that can be made along the way but this > approach is easiest to understand (for me) - it is also by far cheaper > than the huge LUT that was suggested before. > > This is really a nice problem, I am actually considering posting about > it on my blog athttp://asicdigitaldesign.wordpress.com > > cheers, > > Nir Your solution is one of many. While the "key" you mention was the key to your understanding, the cheapest method to implement this may be with 2:1 multiplexers. Take a look at the bitonic sort (please search google) and see how the method might be extended to a simple member flag (1-left nibble, 0-right nibble) rather than full indexing. A few stages of 2:1 muxes (paired 2:1 muxes, actually, to swap two values or pass them unswapped) and you have the result without having to figure out where the middle 1s or 0s are in the 8-bit control vector. - John_HArticle: 129148
>It depends on the interpretation of NC...Some users mistakenly > think it means: Xilinx has Not Connected anything to this pin... I'm aware of the ambiguity, but, when you use an abbreviation, it's your job to make sure the reader knows what it means. This is why, when I see AFAIK, HTH, IMHO etc, I think "another who wants to talk to the world but is too self-important to spend time writing in full". At one time, semiconductor data sheets were superb documents, obviously written by professional technical writers. Now, it's clear that they're often written by engineers who believe that "anyone can write". MikeArticle: 129149
Peter Alfke wrote: > On Feb 15, 9:09 am, MikeShepherd...@btinternet.com wrote: >>> NC is just that: no connect. We reserve the right to do anything we >>> might need to do with these pins, so just follow the rules: do not >>> connect them to anything at all. >> >> There was a time when you could rely on a label like that...when a >> door marked PRIVATE would be respected...when NC meant "NC"...when >> people didn't ask WHO SAYS I CAN'T PRESS THIS BUTTON?? >> >> But hey, it's 2008. >> >> Mike > > It depends on the interpretation of NC. (Beware of the hidden meaning > of Aronyms) > Some users mistakenly think it means: Xilinx has Not Connected > anything to this pin, so I can connect anything I want to it. > The more correct meaning is: Xilinx asks you Not to Connect anything > to this pin, because it might already be used for mysterious > undocumented purposes. > This latter meaning goes back to vacuum tube (valve) sockets in the > 'fourties. > Peter Alfke Austin, Peter, Are you sure? In UG075, the V4 packaging spec., Ch1 introduction it says:- "All of the devices supported in a particular package are pinout compatible and are listed in the same table (one table per package). Pins that are not available for the smaller devices are listed in the "No Connects" column of each table. " I think this means that you can connect up unused pins so that you can upgrade to a bigger part should the whim take you. Unless you have a different idea from me of 'compatible'? Cheers, Syms.
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