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
thanks for the reply. yes ive looked at them. but they dont share pcb layout files. i would like examples that i can use for like... dimensions and component placement examples. maybe something that utilizes different layers.Article: 98001
Martin, You may want to post this on "http://www.niosforum.com" as well. You'll probably get a better/faster response from that Forum. Regards, - BrendanArticle: 98002
Martin wrote: > And the second one I haven't found how to use IRQ of the DMA - is it > functional? The DMA interrupt is definitely functional, although I've only connected it to the NIOS, and not the PCI core. Regards, MarkArticle: 98003
EDK does not map the clock() function to the timers that are present in your system. Instead, you might want to use the XTime_GetTime() function that gives you access to the PowerPC Time Stamp Counter. This counter is incrememnted once on every clock tick, so it can give you the exact # of cycles for the function. /Siva Eric wrote: > Hi, > > I'm trying to measure program execution time in Platform Studio. > I use two clock() functions from time.h before and after the code > section > I want to take the measurement. When I compiled the program, I > received the following errors: > > /cygdrive/c/EDK/gnu/powerpc-eabi/nt/bin/../lib/gcc/powerpc-eabi/3.4.1/../../../../powerpc-eabi/lib/libc.a(timer.o)(.text+0x10): > In function `_times_r': > /cygdrive/x/gnu_builds/halite/env/Jobs/MDT/sw/nt/gnu1/ppc_newlib_src/newlib/libc/reent/timer.c:64: > undefined reference to `times' > /cygdrive/c/EDK/gnu/powerpc-eabi/nt/bin/../lib/gcc/powerpc-eabi/3.4.1/../../../../powerpc-eabi/lib/libc.a(timer.o)(.text+0x68): > In function `_gettimeofday_r': > /cygdrive/x/gnu_builds/halite/env/Jobs/MDT/sw/nt/gnu1/ppc_newlib_src/newlib/libc/reent/timer.c:108: > undefined reference to `gettimeofday' > collect2: ld returned 1 exit status > > Does anyone know what's wrong? Thanks plenty! > > -EricArticle: 98004
Frank @ CN wrote: > In my application, a RAM needs to be written/read from two sets of > data/address ports > simultaneously. However, in the ASIC library I can only instantiate some > single port RAM > and RAM which can be written in one port and read from the other port. > > How shall I solve this problem? If you have a faster clock available, one common way to solve this kind of problem is to time-division multiplex the 1-ported RAM. Essentially run two (or more) successive memory read/write cycles one the ASIC, per one read/write time slot on the FPGA. You can also use this technique inside an FPGA to make the fast dual-port RAMs look like 4 or more ported, but slower, memories. IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-MArticle: 98005
In article <1140607536.898669.244660
@g44g2000cwa.googlegroups.com>, fpga_toys@yahoo.com
says...
[ ... ]
> I've also wondered what would happen if I took a neutron emitter to
> vegas to play the slots :)
> Or to Blackhawk. Do they disallow big wins when the machine locks up
> or glitches? Do they have detectors at the door?
Nearly all of these machines have BIST routines to run
immediately before announcing a large payout. Some have
BIST routines to run more or less continuously.
> Given the rosetta numbers Xilinx gathered at this altitude, it seems
> that a few thousand slot machines with FPGA machines in them would be a
> huge reliability problem at Blackhawk .... or even a lot of small
> micros with static rams. Does the gaming commissions even consider the
> hardware might be less reliable than the software that they also
> strictly regulate like the medical folks?
Gaming machines mostly don't need a lot of speed so many
use pretty old technology. I'm pretty sure I've never
seen one with an FPGA in it, at least in any critical
area (though, in fairness, I've only looked at the
innards of a few).
The systems tend to be bifurcated into two pieces: one
part runs on a fairly standard low-end PC, generating the
display, sound, flashing lights, etc.
The other part is the random-number generator stuff that
actually decides when games are won or lost. This has its
own dedicated CPU and the software runs directly
from ROM. At least in the machines I looked at, this
would have no problem in Blackhawk...or a satellite.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 98006Hi, there I want to use GPIO to control the LED. Before that, I need to use XStatus XGpio_Initialize(XGpio *InstancePtr, Xuint16 DeviceId); to instiantiate a GPIO object. Here, I use a "LEDs_4Bit" IP but I don't know what's the DeviceId for it. Could anybody tell me what's the Device Id, and where could I find it? Thank you for the help RogerArticle: 98007
Jerry Coffin wrote: > In article <1140607536.898669.244660 > @g44g2000cwa.googlegroups.com>, fpga_toys@yahoo.com > says... > > [ ... ] > > > I've also wondered what would happen if I took a neutron emitter to > > vegas to play the slots :) > > Or to Blackhawk. Do they disallow big wins when the machine locks up > > or glitches? Do they have detectors at the door? > > Nearly all of these machines have BIST routines to run > immediately before announcing a large payout. Some have > BIST routines to run more or less continuously. > > > Given the rosetta numbers Xilinx gathered at this altitude, it seems > > that a few thousand slot machines with FPGA machines in them would be a > > huge reliability problem at Blackhawk .... or even a lot of small > > micros with static rams. Does the gaming commissions even consider the > > hardware might be less reliable than the software that they also > > strictly regulate like the medical folks? > > Gaming machines mostly don't need a lot of speed so many > use pretty old technology. I'm pretty sure I've never > seen one with an FPGA in it, at least in any critical > area (though, in fairness, I've only looked at the > innards of a few). > > The systems tend to be bifurcated into two pieces: one > part runs on a fairly standard low-end PC, generating the > display, sound, flashing lights, etc. > > The other part is the random-number generator stuff that > actually decides when games are won or lost. This has its > own dedicated CPU and the software runs directly > from ROM. At least in the machines I looked at, this > would have no problem in Blackhawk...or a satellite. An episode of "Breaking Vegas" on the History Channel called "Slot Scoundrel" was about someone who successfully cheated slot machines using electronics. They didn't detail how it was done, but the photos made it look like he use a probe on a piece of metal to hook into a JTAG connector and reprogram the random number generator. One view had a big picture of a Xilinx chip, but this may have been creative license of the show producer. The casino investigated, found the machine to be fine and paid out. He was turned in by an accomplice. Alan NishiokaArticle: 98008
In article <1141359422.544571.134770
@j33g2000cwa.googlegroups.com>, alan@nishioka.com says...
[ ... ]
> An episode of "Breaking Vegas" on the History Channel called "Slot
> Scoundrel" was about someone who successfully cheated slot machines
> using electronics. They didn't detail how it was done, but the photos
> made it look like he use a probe on a piece of metal to hook into a
> JTAG connector and reprogram the random number generator.
>
> One view had a big picture of a Xilinx chip, but this may have been
> creative license of the show producer.
That's hard to say with any certainty -- the ones I've
seen didn't use anything that was re-programmable after
the fact without swapping out parts, but there are a lot
of designs out there, and I've only looked at a couple of
them.
I can imagine an FPGA for something like the glue logic
to get their weird peripherals to talk to the computer --
they have lots of flashers and stuff that nearly nobody
else on earth ever has or probably ever will want to
connect to their windows box.
In the PRNG itself, however, I'm left wondering what
they'd do with an FPGA if they did have one. Their
performance requirements are minimal, and the
requirements are nearly carved in stone, so they
practically never change.
The instances of which I'm aware that people cheated
relatively successfully have involved electronics they
put next to the machine, not something where they
modified the machine internally at all. Oddly enough,
however, they weren't particularly forthcoming with
details about how they worked either...
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 98009Following up on that earlier ADS5273 thread, where I wrote: > > One thing that jumped out at me from the ADS5273 datasheet >was the output slew rate and impedance specs: > > LVDS Outputs Rise/Fall Time (typ) > 2.5mA 400 ps > 3.5mA 300 ps > 4.5mA 230 ps > 6.0mA 180 ps > > Differential Output Impedance > 13 Kohm > > If you hook such a part directly to an FPGA with 10 pF of >input capacitance, Very Bad Things will happen to your >840 Mbps data due to the input reflections off the FPGA. > I've put together a simple LTSpice simulation model of that interconnection ( model is completely unverified ) slides at: http://members.aol.com/Fpgastuff/lvds_current.pdf zip including .pdf and LTSPICE files http://members.aol.com/Fpgastuff/lvds_current.zip BrianArticle: 98010
It's great to see so much interest in partial reconfiguration. I posted on Feb 14, but mayby wasn't clear. We have developed new tools and a new flow for partial reconfig. That software works with ISE 8.1i, but is not included with ISE 8.1i. You need to contact your local FAE to get the software. Steve Sean Durkin wrote: > Vic Vadi wrote: > >>The Virtex4 hardware supports partial reconfiguration and includes a lot >>of special hooks intended to increase the flexibility of usage of >>Partial Reconfig. Unfortunately the tools haven't quite caught up yet. >>This should improve with the new Plan Ahead 8.1 and future Software >>releases. > > This is exactly what I've been hearing since I started out with partial > reconfiguration, and that was with ISE4.2. "Will be fixed in the next > service pack", "should work in the next release", "This is not supported > yet, but well be later on.", "This is a known issue that is scheduled to > be fixed in a future software release.". > Kind of reminds me of GNU/Hurd, which is always scheduled to be usable > "next year", or "Duke Nukem Forever", which has been scheduled to be > released for the past 9 years. > > Now it's 4 major releases and probably a dozen service packs later, and > the bottom line is: It has never worked properly, it still doesn't, and > in the past few years support in the tools hasn't even gotten a little > better, because all the problems seem to be re-introduced with every > major release all over again. And of course, as soon as a new FPGA > family is introduced (Spartan 3, Virtex 4), all the effort seems to be > going (understandably) into implementing partial reconfiguration for > these new devices, not into fixing bugs in the existing support for > older devices. > > The high-point of all of this was with the release of ISE7.1, when > partial reconfiguration was completely disabled until SP4. > > >>Some applications like Software Defined Radio and >>Reconfigurable Computing are driving this. > > Nice to hear that now *finally* there seem to be applications for the > mass market that make the whole subject "interesting" to Xilinx. > > In past years the whole thing was more or less academic in nature, and I > totally understand that priorities are low when there's only little or > no money behind it. This is all perfectly reasonable and understandable. > > But the thing that bugs me is that Xilinx has been using partial > reconfiguration to promote their parts for years, and as soon as you > really dive into the subject you find out that the parts do indeed > support it, but the software does not, or has only very buggy or > rudimentary support. > > So when you ask someone from Xilinx you usually get a link to some > marketing press release which states "Yes, partial reconfiguration > works, we're better than all of our competitors!", which is obviously > only part of the truth... > > cu, > SeanArticle: 98011
Hub van de Bergh wrote: > Does a VHDL programmed FPGA concern software or hardware? > > As usual also this issue can be approached from different viewpoints. > One viewpoint can be the realization process, > Another viewpoint can be blackbox testing of the programmed FPGA device, > whether or not 100 % coverage can be achieved. > You will certainly be able to add your own viewpoints and your personal > opinion to this question. > Does a VHDL programmed FPGA concern software or hardware? Should software > engineering methodologies be applied or is it more likely application of > switching theory and logical design or ..... > And what about design verification & validation? > What do you think? > > www.hvdb.tk hi, i am doing project on "FPGA implementation on Sin/cosine generator using CORDIC Algorithm" please help me about it param_singh_21@rediffmail.comArticle: 98012
> I think for Ham radio, 2E48 is a bit overkill, unless you are doing > coherent detection... Thanks Austin but isn't an Ham project...in the Web we can find thousand projects/kits ready-to-use for Ham. Bye. -- 73's de IZ5FCY RobertoArticle: 98013
agou wrote: > Hi, there > > I want to use GPIO to control the LED. Before that, I need to use > XStatus XGpio_Initialize(XGpio *InstancePtr, Xuint16 DeviceId); to > instiantiate a GPIO object. > > Here, I use a "LEDs_4Bit" IP but I don't know what's the DeviceId for > it. Could anybody tell me what's the Device Id, and where could I find > it? > > Thank you for the help > Roger > This ID can be found in the xparameters.h file which is automatically generated by the EDK. If you have, for example, the following block in the .mhs file: BEGIN opb_gpio PARAMETER INSTANCE = opb_dbg_leds PARAMETER HW_VER = 3.01.a PARAMETER C_GPIO_WIDTH = 4 PARAMETER C_ALL_INPUTS = 0 PARAMETER C_BASEADDR = 0x80004200 PARAMETER C_HIGHADDR = 0x800043FF PORT GPIO_IO = dbg_leds BUS_INTERFACE SOPB = opb_bus END Then the ID would be like: XPAR_OPB_DBG_LEDS_DEVICE_ID. FrankArticle: 98014
Hi Frank, >From what I have read in the documents (I have not implemented the complete flow yet), the support for partial reconfiguration has indeed evolved in Virtex 4. First, the Planahead tool handles modular based flow better than just the floorplanner in the previous modular based flow. Second, the Virtex 4 has fixed size frames (16 clbs) based partial reconfiguration rather than a column based partial reconfiguration. This basically means that there can be multiple frames in one column of any Virtex 4 device. Thus, the whole column does not have to be reconfigured all at once. This could reduce a lot of complexity for interconnects that connects one side of reconfigurable region to another side (they do not have to be routed using long wires only, for example). I think designs with partial reconfiguration could be implemented better in Virtex 4 than in Virtex 2, but as I said, I have not yet implemented the complete flow. Love Singhal http://www.ics.uci.edu/~lsinghalArticle: 98015
>> You've had to understand the target architecture and what's causing your >> timing constraint to fail, then re-jig your HDL to reduce the number of >> levels of logic to achieve timing closure. > Not at all. Programmers juggle instruction/statement flow all the time > to reach timing closure in C and asm for device drivers and embedded > applications in many fields But you're not just juggling lines of code about so the order of execution is different (ie to make sure things are picked up quickly enough in an ISR or whatever). > Looking at the problem a little more this afternoon, the C based 66mhz > PCI core is looking much more viable. The combinatorial length was > actually from unnecessarily including the main references to the pci > bus signals in the else side of the reset conditional. Breaking that > dependency changed the base FSM speed from 63mhz to better than 73mhz, > making it likely the other setup and hold times can be met as well. I still think this is an accurate observation... "You've had to understand the target architecture and what's causing your timing constraint to fail, then re-jig your HDL to reduce the number of levels of logic to achieve timing closure." Nial.Article: 98016
"Brian Davis" <brimdavis@aol.com> wrote in message news:1141364601.057606.323670@i40g2000cwc.googlegroups.com... > > I've put together a simple LTSpice simulation model of that > interconnection ( model is completely unverified ) > > slides at: > http://members.aol.com/Fpgastuff/lvds_current.pdf > > zip including .pdf and LTSPICE files > http://members.aol.com/Fpgastuff/lvds_current.zip > Brian, Top-notch post! You demonstrate the problem perfectly and describe how to work around it. It's a shame that this kind of thing tends not to appear from the FPGA manufacturers. Rather than admit their parts sometimes have to be a compromise between the needs of many diverse users, they seem to prefer to say their devices are all things to all men. What you've so ably shown is how, by being aware of the FPGAs' limitations, a solution to the 'bleak' Cpin is possible. Thanks for taking the time to produce and publish your results. Cheers, Syms. p.s. And ta for the reference[4]!Article: 98017
"Jerry Coffin" <jcoffin@taeus.com> wrote in message news:MPG.1e7179ac295ac16b9896d4@news.sunsite.dk... > In article <1141359422.544571.134770 > @j33g2000cwa.googlegroups.com>, alan@nishioka.com says... > > [ ... ] > >> An episode of "Breaking Vegas" on the History Channel called "Slot >> Scoundrel" was about someone who successfully cheated slot machines Guys, If you go to Amazon and look for Kevin Mitnick's book "The art of intrusion" you'll find you can read the first chapter, entitled "Hacking the Casinos for a Million Bucks", for free. You might find it interesting. Cheers, Syms.Article: 98018
"Steve Lass" <lass@xilinx.com> wrote in message news:4407EC49.7060706@xilinx.com... > It's great to see so much interest in partial reconfiguration. I posted > on > Feb 14, but mayby wasn't clear. We have developed new tools and a new > flow > for partial reconfig. That software works with ISE 8.1i, but is not > included with > ISE 8.1i. You need to contact your local FAE to get the software. > Hi Steve, Are any non-academic customers using this flow with reliable success? My point being, it's probably a great post-graduate project, but should I be willing to bet my companies R&D money on it? Is there a commitment from Xilinx to support this design flow into the future? I'd like to see some IP cores based on this being released by Xilinx. It would show that the Xilinx IP developers believe in it! Please don't get me wrong, I'm typing in a friendly tone of voice! I really hope you guys have it cracked this time. I hope you can understand the caution expressed by some of the more cynical posters on CAF!! Many thanks, Syms.Article: 98019
"Symon" <symon_brewer@hotmail.com> wrote in message news:44083507$0$15795$14726298@news.sunsite.dk... > willing to bet my companies R&D money on it? Is there a commitment from I meant "company's". Arse.Article: 98020
Hallo, the Atmel flash memory present on the MiniModule can be used to store software application code? Many Thanks MarcoArticle: 98021
I am trying to use the jtag interface as a general purpose communication port. I looked at the GNAT module (http://www.s3group.com/system_ic/gnat/). I
think I understand the vhdl part. Now the other side at the pc. I am trying to write the user code into the device in order to get something done, but
it doesn't seem to work. The script I use is as follows:
source c:/xilinx_7_1/ChipScope_Pro_7_1i/tcljtag.tcl
set handle [jtag_open]
jtag_lock $handle
jtag_autodetect $handle
jtag_shiftir $handle -buffer "0100001111" -endstate RTI -device 2
jtag_shiftdr $handle -buffer "1010101000000001" -endstate RTI -device 2
jtag_unlock $handle
jtag_close $handle
A few questions about this:
- the virtex4 has up to four usercodes. What are the bit defines for these usercodes?
- is one usercode attached to one bscan_virtex4 component?
- how to deal with the endstates in the jtag_shiftir and jtag_shiftdr calls?
- is the script above something that should work or is it complete nonsense? (all I want to do is send the value 0x8055 to the second device in the
jtag chain)
Extra information: I have instantiated the bscan_virtex4 component with the following generic
bscan_virtex4_inst : bscan_virtex4
generic map (
jtag_chain => 1
)
.
.
.
I assume the jtag_chain attribute matches with the usercode to use (jtag_chain of 1 will specify to use usercode 1), is this correct?
By the way, tcl is new for me (in the sense that I never programmed in tcl before).
TIA,
Frank
Article: 98022
Symon wrote:
>
> It's a shame that this kind of thing tends not to appear from the FPGA manufacturers.
>
Yes, one would certainly expect to see some IBIS or SPICE
simulations provided along with XAPP774.
Unlike the current crop of app notes and marketing fluff, the
original Virtex-E LVDS app notes weren't afraid to plot LVDS
waveforms at points other than only the on-die receiver input of
a perfectly back terminated line. ( Speaking here of the general
purpose LVDS I/O app notes; the Rocket I/O stuff is generally
better done. )
For a real chuckle, read :
XAPP756 Transmitting DDR Data Between LVDS and RocketIO CML Devices
Surely you'd see plenty of reflections with a 60 ps rise time
CML driver whacking a 10 pf LVDS input pin, right?
But not when the only waveform plotted is a worst-case loss situation,
showing only the receiver inputs, after driving four feet of FR4...
>
> p.s. And ta for the reference[4]!
>
I liked that "c{r}appy LVDS" pun.
Brian
Article: 98023On 01 Mar 2006 15:37:30 -0800, Eric Smith <eric@brouhaha.com> wrote: >+<"nezhate" <mazouz.nezhate@gmail.com> writes: >+<> Hi all, I want to use a small cricuit (written in verilog and was >+<> designed using ISE 3) in an other project using ISE 8.1. the problem is >+<> that under ISE 3 the circuit worked perfectly, and under ISE 8.1 the is >+<> an error. why this occur ? >+< >+<Probably because you're not rubbing together a regurgitative purwell and >+<a supramitive wennelsprock. >+< >+<You might get better results after reading: >+< >+< http://www.catb.org/~esr/faqs/smart-questions.html ***** Oh no the net police!!! jamesArticle: 98024
yes
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