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
There are two conclusions: either Lattice is BS'ing (but I heard the same - and even more it is possible to use an Atmel SPI flash by overriding the reading of the vendor code), or worse Altera has played some dirty trick with their customers by selling the Atmel SPI flash for a silly high price. To the reader to decide which is true - and draw their conclusions. I took mine and asked for samples of the ECP10 vs. S10 for a new application. The price I got is lower than the S10 and it is truly programmable with any SPI Flash. Best regards, Luc On Thu, 03 Feb 2005 13:43:03 GMT, Jedi <me@aol.com> wrote: >Ulf Samuelsson wrote: >>>If I would make a top list for SPI flash it would look like: >>> >>>1. SST >>>2. ST >>>3. Nexflash >>> >>>best regards >>>rick >>> >>> >>>ps: And still no answer given regarding Atmel making EPCS chips >>> for Altera (o; >>> >>> >> >> >> >> I certainly have not heard anything about this. >> Checked out the different alternative. >> >> Nexflash is nice due to uniform sector size. All parts seems to have 256 >> byte pages. >> It makes it easy to do a FAT file system w 512 B sectors. >> Fairly low current, both in read (4 mA) and in power down (1 uA) >> 64 kB Sector erase time sucks greatly - 2 seconds !!! >> Single RAM page in the device, so you have to wait until the device >> is ready until you shift in more. >> Max size 16 Mbit... >> >> SST is very quick to program/erase - 70 msa for chip erase. 18 ms for block >> erase. >> The 4 kB sectors makes the part harder to use, since it becomes hard to >> allocate >> a block for a single data entity. >> Single SRAM page, byte write is nice. 100 years data retention. Is this to >> be believed? >> 33 Mhz operation is also nice. >> Is only useable for 3.0V-3.6V - No mobiles phones ...(Run at 2.8 V) >> Anything larger than 8 Mbit? .... >> >> ST - 8 Mbit >> 64 kB Sector erase time is up to 5 seconds (he he he..) Say no MORE... >> >> Comparing them to the AT45DB642 (which is several years old) >> 1056 byte sectors, note: Not 1024: this measn that the extra bytes you >> need for handling the flash like CRC, erase count etc are inside the >> sector... >> >> Dual SRAM page, which means that you can load in a page, >> start programming the page and while the programming is in progress >> you can start loading the next page. >> >> 4 mA read current, and 2 uA power down current. >> 18 ms page programming, but the page size is 4 x Nexflash and >> they will need to shift in between every programming cycle, so >> in reality, they are quite close. >> >> 18 ms block erase. This is 8 pages or8 kB, so multiply by 8 >> to get 144 ms per 64 kB block. Obviously it is faster, if you are happy >> with erasing a block. >> >> Lacks byte programming unlike SST. >> 20 Mhz clock rate is a little low, but it will soon increase to 50 Mhz >> and the size will also increase to 128 Mbit. >> >> I leave it to the reader to draw conclusions. >> > >Okay...finally received Atmel samples of AT25F1024A and AT25F4096. >Both are not working as replacement for EPCS configuration for Cyclone FPGA. > > >rickArticle: 78976
"nospam" <nospam@nospam.invalid> wrote in message news:ltcn015r60dkl5gtm7kme5nd73lg17rdad@4ax.com... > "newman5382" <newman5382@yahoo.com> wrote: > >> >>"nospam" <nospam@nospam.invalid> wrote in message >>news:l67n01l0igpcron5qtc7u322lkqpgp23bl@4ax.com... >>> "newman5382" <newman5382@yahoo.com> wrote: >>> >>>>> Did you or anyone else get the now bundled EDK evaluation (and 6.3i >>>>> ISE >>>>> evaluation I presume because the 6.3i EDK appears to need it)? >>> >>>>I have not got my EDK either. The Spartan III starter kit came with the >>>>ISE >>>>eval CD's >>> >>> ISE 6.2i? >> >>ISE 6.3i. > > The Xilinx online shop still says the starter kit ships with ISE 6.2i > which > is what mine came with. > > Please add to this thread if you have any news, I will if I hear something > from my distributor. > > Well, I guess they must have shipped me the wrong CD by mistake, cause it says 6.3i. Anyhow, you can get a 60 day ISE6.3 eval CD from the Xilinx Online store for the cost of shipping. -NewmanArticle: 78977
Hi Sergio! > > I am currenlty migrating some software from an XC3400-4PQ208 to a > SPARTAN-3 XC3400-4TQ144. The software and everything is running > perfectly in the previous spartan. I have created a new project for > the > TQ144 and synthesised it without any error. However, when I run the > PACE software to assign the pins, the Design Rule Check gives me lots > of errors with the same legend "The bank number specified does not > exist", It is worth to note that I am not assigning the bank, I am > assigning a pin and PACE selects the Bank by itself. The bank for each > I have the same problem using a 50k Spartan3 in TQ144 package. You can just assign the pins in the UCF file manually. Afterwards you can run PACE to generate area constraints and so on, PACE only mixes the line order in the UCF file. If you run a design-rule check it still compains about the bank. At least I have not found any problem regarding the functionallity of the FPGA, so dont worryi:-). Best regards, ChristophArticle: 78978
> Maybe you need to rewrite your program so its smaller when compiled? > Actualy although I am not a big fan of embedded processors within > FPGAs it does make people rediscover the art of writing efficient code. There is no way to rwrite it more effecient, and btw: its only 200 lines, thats nothingArticle: 78979
Ricardo wrote: > Ben Popoola escreveu: > >> Rick Fox wrote: >> >>> Hello, > > <snip> > >>> >>> Rick Fox >>> (Belmont Special School) >>> Manchester, UK. >> >> >> >> >> Hi Rick, >> >> Unfortunately, the 'S' in the EPM7128SLC84 part indicates that this >> part cannot be programmed with a byteblaster cable. The new part that >> can be programmed is probably an 'A' part i.e EPM7128Axxx. >> >> It might be worth contacting an Altera FAE to see whether they are >> willing to program these parts for you. >> >> Regards >> Ben > > > The S says it can be programmed with the BB cable, although the Jtag > pins can be programmed as IO, disabling the Jtag interface with no way > os bringing it back AFAIK without a master programmer. > > Ricardo Whoops, my mistake.Article: 78980
I am using jtagppc_cntl in the design. I will try using the XMD commands. Thankyou for your help Adrian "newman5382" <newman5382@yahoo.com> escribió en el mensaje news:HEOOd.11034$pc5.3292@tornado.tampabay.rr.com... >I take it that the stop, rst command in XMD before you start gdb did not >help. > > Are you using the jtagppc_cntl in the V2Pro design? If so, the serial > baud rate should not be an issue at this point in time. > After you do a ppcconnect in xmd, can you do a stop, rst, srrd? > The srrd should dump a bunch of Power PC registers. If it does not do > these things, there is little point in trying to get gdb to work. > > -Newman > > > "adrian" <adrian.mora@terra.es> wrote in message > news:NyNOd.295281$A7.410288@telenews.teleline.es... >> Has anyone ever encountered a problem of this type? >> >> "newman5382" <newman5382@yahoo.com> escribió en el mensaje >> news:9VMOd.57800$JF2.36411@tornado.tampabay.rr.com... >>> >>> "adrian" <adrian.mora@terra.es> wrote in message >>> news:fxMOd.290563$A7.405663@telenews.teleline.es... >>>> Hi to everyone, >>>> >>>> I am quite stucked with a problem for several days and I would like to >>>> ask for some possible help. >>>> >>>> I am trying to download a project to a Avnet Board on a Virtex 2 Pro >>>> xc2vp7 and debugging with XMD and GBD from EDK 6.3 through JTAG >>>> parallel cable IV. >>>> First of all I download my design (download.bit) with the download >>>> option from the tools menu of EDK. Ok >>>> After that finishes correctly I open XMD form a Xygwin shell and type >>>> 'connect ppc hw' to connect to the PowerPC core and everything seems to >>>> work correctly since I get the message: >>>> >>>> xmd: starting gdb server for "ppc" target <id=0> at TCP port 1234 >>>> >>>> I assume that this assures that the PowerPC degugger is listening at >>>> port 1234 for any GBD requests. >>>> But when I connect to 'localhost' to port '1234' with the software >>>> debugger I always recieve the same messages from the XMD console: >>>> >>>> Accepted a new GDB connection from 127.0.0.1 on port 2325 >>>> >>>> putpkt<read>: invalid argument >>>> >>>> Closed GDB connection from 127.0.0.1 on port 2325 >>>> >>>> This always occurs either choosing 'run' (the code) or 'connect to >>>> target' on GBD. >>>> After a while I get a Windows alert message with: >>>> >>>> >>>> GDB >>>> >>>> >>>> Couldn't establish connection to remote target >>>> >>>> Malformed response to offset query, timeout >>>> >>>> GDB cannot connect to the target board using localhost:1234. >>>> >>>> Verify that the board is securely connected and, if necessary, >>>> >>>> modify the port setting with the debugger preferences. >>>> >>>> I am connected to the board with hyperterminal 9600 bauds with a serial >>>> cable, the JTAG parallel cable is powered and so is the board. The >>>> board lights seem to be all ok. No malfunction. >>>> >>>> I really don't know why I can't start downloading the .elf file to the >>>> board. For some reason the debug core isn't accepting requests from the >>>> software debugger. Could the baudrate be the problem? The board serial >>>> port works on 9600 bauds, I even tried choosing other baudrates >>>> concluding the same. Am I missing something? >>>> >>>> Thanks a lot. >>>> Adrian. >>>> >>> Adrian, >>> Sometimes I have found that after opening XMD and doing a ppcconnect, >>> that if a issue a stop, and then a rst from XMD before I invoke gdb, it >>> works better. >>> >>> - Newman >>> >>> >> >> > >Article: 78981
Hi I am working with Microblaze on an Xilinx ML300 board. I have added more C code to my program which is testing my own FSL IP Core When I try to add more C Code to my program for the FPGA I get the following error: mb-gcc -O2 TestApp/src/TestApp.c -o TestApp/executable.elf \ -mno-xl-soft-mul -Wl,-T -Wl,TestApp/src/TestAppLinkScr -I./microblaze_0/include/ -L./microblaze_0/lib/ \ -xl-mode-executable \ mb-ld: region ilmb_cntlr is full (TestApp/executable.elf section .bss_stack) make: *** [TestApp/executable.elf] Error 1 Done. Is there not enough memory for the C Code available? So that I just have to generate a new Microblaze core which has more RAM available? Or what could be the reason for this? THanks for any hint ClemensArticle: 78982
Is it possible?Article: 78983
Hi Nahid, If you want to cheat, you can compile it with the Nios tools and look at the *.out file - I think that's the right file (don't have a Nios environment here with me). This file has the C code interspersed with the generated assembly. I'll bet you can do a better job at assembly that Nios I's compiler. -- Pete [ p s o m m e r f e l d (at) gmail.com ] Nahid wrote: > I'm trying to implement the following C++ code using NIOS processor's native > instruction set. > > int A; > int B; > for (int i = 0; i < B; i++) > A = (A<<1)+4; > > Could some1 step out to point me in the right direction of how I am supposed > to do this? > > Thanks...Article: 78984
Yes. Same as using a processor to do the same thing.Article: 78985
Maybe you need to rewrite your program so its smaller when compiled? Actualy although I am not a big fan of embedded processors within FPGAs it does make people rediscover the art of writing efficient code.Article: 78986
Martin Schoeberl wrote: > Another idea: What do you guys think about adding a slot for a SD Card [1]. > They are cheap (about EUR 10,- for 128MB) and you get them up to 1GB! > However, the impact on the board is high: The connector is 'big' and > increases the board hight. A FPGA with a higher pin-count is needed. For > the solution without the SD Card a 100pin TQFP would fit, but now a 144pin > is needed - again a larger board. > And this adds again a few EUR/$. All these design decissions! You start with > a minimal core design and than start adding (unnecesssary) features again. > > BTW: Has somebody inplemented an SD Card interface in an FPGA. It should > not be too hard [2]. The simplest solution would be the SPI bus. You might want to consider two variants: one that is on the KISS path, and is on the lower price knee, and just sufficent to operate a workable JOP, and another that is more maximal, and more able to launch an operating system as well. For package, I'd vote against pin-modules, as they are expensive to make, have a pin count ceiling, and are easily damaged. The only benefit is they can save a little time in first deployment. Better are the memory-card formats, as they have low cost and sturdy connections, that can still be socket managed on 1 & 2 layer PCB, and you can offer a socket-pcb for users starting from nothing. Besides the simmmstick itself, you should consider the SODIMM modules, as seen in TINI : http://www.maxim-ic.com/products/tini/pdfs/TINI_GUIDE.pdf For "smart expansion", SD would be one option, but smaller and more flexible might be USB-Drive ?. Not as cheap at the lowest node, but universally portable - few PCs can R/W SD cards, but they can all R/W a USB drive. Of course, that means the FPGA needs to be smarter :) -jgArticle: 78987
Marco wrote: > Is it possible? > > It's very simple in case of a printer having a centronics interface. Even graphics can be done easily after sending the right commands. In case of a USB printer you will need a USB host. Implementing that in an FPGA will be much more difficult, so buy an old fashion HP500 Deskjet from Ebay and use that one (: Best Regards, RoelArticle: 78988
Thanks so much for your good advice. I hope that you take that vacation soon! I would love to try your idea out. can I email you for help? OrenArticle: 78989
Has anyone used the variable phase shift in Spartan3 DCMs? My
potential application will dither the receive clock and then filter the
incoming data to obtain a much finer than clock cycle resolution on time
of arrival measurements on a digital one bit input. The phase shift
update rate would be about 3 MHz, and each phase update is simply an
increment or decrement. I'm hoping to get in the neighborhood of 300ps
resolution by reading the repetitive input signal with the phase of the
input register clock in/decremented on successive takes over roughly 180
reads.
The questions are:
Does it work as advertised?
Is the time from PSEN to phase change constant for fixed clkin, psclk
frequencies and constant DCM parameters other than the phase shift?
I assume the output jitter is the +/-150ps specified plus whatever
jitter is present on clkin. Is that correct?
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 78990Hi, we boot our fpga´s via pci with special boot logic in the pci-spartan. We are using the slave selectmap mode (M[2:0]="110"). Normally the bootprocess and startup works fine - but sometimes there is a mysterious problem: 1.) Done appears and is signalled to the boot device. 2.) FPGA is not working/responding to external requests This happens 1 of 100 times we boot the fpga, and we have no chance to detect that (without trying some access to the normal IO´s), because we only use the DONE as an indication. The last time this appeared I was clever enough to ask Chipscope to read the status register of all three devices in the additionally available jtag chain. Here are the results (first not working, others do) COMMAND: show_config_status 0 INFO: Bits [15 ..0]: 0001 1110 1100 1100 Bit 15: 0 RESERVED Bit 14: 0 RESERVED Bit 13: 0 ID_ERROR Bit 12: 1 DONE Bit 11: 1 INIT_B Bit 10: 1 MODE M2 Bit 9: 1 MODE M1 Bit 8: 0 MODE M0 Bit 7: 1 GHIGH_B Bit 6: 1 GWE Bit 5: 0 GTS_CFG Bit 4: 0 IN_ERROR Bit 3: 1 DCI_MATCH Bit 2: 1 DCM_LOCK Bit 1: 0 RESERVED Bit 0: 0 CRC_ERROR COMMAND: show_config_status 1 INFO: Bits [15 ..0]: 0001 1110 1110 1100 Bit 15: 0 RESERVED Bit 14: 0 RESERVED Bit 13: 0 ID_ERROR Bit 12: 1 DONE Bit 11: 1 INIT_B Bit 10: 1 MODE M2 Bit 9: 1 MODE M1 Bit 8: 0 MODE M0 Bit 7: 1 GHIGH_B Bit 6: 1 GWE Bit 5: 1 GTS_CFG Bit 4: 0 IN_ERROR Bit 3: 1 DCI_MATCH Bit 2: 1 DCM_LOCK Bit 1: 0 RESERVED Bit 0: 0 CRC_ERROR COMMAND: show_config_status 2 INFO: Bits [15 ..0]: 0001 1110 1110 1100 Bit 15: 0 RESERVED Bit 14: 0 RESERVED Bit 13: 0 ID_ERROR Bit 12: 1 DONE Bit 11: 1 INIT_B Bit 10: 1 MODE M2 Bit 9: 1 MODE M1 Bit 8: 0 MODE M0 Bit 7: 1 GHIGH_B Bit 6: 1 GWE Bit 5: 1 GTS_CFG Bit 4: 0 IN_ERROR Bit 3: 1 DCI_MATCH Bit 2: 1 DCM_LOCK Bit 1: 0 RESERVED Bit 0: 0 CRC_ERROR As you can see the GTS_CFG status bit is not set. This means that the IOB´s are not switched into running mode. That makes sense because we see that the IOBs are tristated.On our bitgen option we use the default startup sequence DONE_CYLCLE=4, GTS_CYLCLE=5,GWE_CYCLE=6. What can cause the fpga not to release the GTS_CFG_B pin? Could it be a timing problem with DONE? Maybe DONE pullup is to weak? We additionally always use DRIVE_DONE, so this should not be the problem. Any suggestions ? kind regards, thomasArticle: 78991
Pete, I used opb_emc EDK6_2i with a PPC. I also used the P160 Insight board for the XC2V1000. I got it to work . Watch out to get the sram_ben paired up correctly with the data. If you get the order messed up with sram, you can write it "wrong" and read it back "wrong", and it will look correct. The read only flash ID is another story. I set PARAMETER C_NUM_BANKS_MEM = 2 Added another address range for the additional (flash) bank. This resulted in sram_cen to be a vector. one for the sram and one for the flash. Lastly, I had to increase the amount of time required to access the flash. It was slower than the sram portion. It was nice to watch the transactions using chipscope. Good luck, - Newman "PH" <p_hogan76@yahoo.co.uk> wrote in message news:1108035036.583034.235520@c13g2000cwb.googlegroups.com... > Hi, > > I'm trying to do reads/writes to a flash device on our board using the > Microblaze processor. The part itself is the same as featured on the > Insight board for the XC2V1000 eval board. > > When I simply try and read back the manufacturer and id codes, I get > the value 0x00AA00AA instead - incorrect value. Any erase or write > operations also fail. > > I'm using EDK 6.3 and an opb_emc peripheral - I used to use an > opb_memcon (I think) on previous versions of the EDK and this worked ok > with the same board. > > It's a combined SRAM/Flash device and the SRAM works ok. I've no clue > why it now fails. > > Cheers, > > Pete. >Article: 78992
Ray, I will try to find out.What clock frequency? But in the meantime, I would use Virtex-4LX25 (plentifully available) and use its fine-grained input delay line, severalof them in inparallel, with 80 ps difference between them. You would not have to make multiple measurements, just one would give you the answer. But I know you are smart enough to figure this out, plus more tricks...:-) I'm in love with that 64-tap input delay line... Peter AlfkeArticle: 78993
--------------070006050206060905080304
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hal Murray wrote:
>>Another is a safety-related reset, perhaps in a motion control system,
>>where you
>>need the reset to halt motion and cause an emergency stop, even if the
>>clock were
>>to fail. I have something like this in some of my designs. The
>>external, analog-based
>>one-shot watchdog timer will cause an e-stop even if the clock to the
>>FPGA has
>>gone static. I don't have any problem with an asynchronous release of
>>this reset,
>>in this case. it could cause a problem with a simulation, but it won't
>>cause any
>>problem in the actual application. The worst case is one more
>>millisecond before
>>the e-stop condition ends.
>>
>>
>
>I missed something. This is a safety critical application. Why
>aren't you concerned about coming out of asynchronous resets?
>
>[It's one of my hot buttons. I learned the hard way.]
>
>
>
The way the circuit works, it requires communication from the CPU to
satisfy the watchdog, all other external fault conditions must be clear,
then
the command to come out of emergency stop must be given, and the global
e_stop\ bus signal must rise under resistive pull-up to the logic threshold
DURING the duration of the come out of estop command strobe. If it
doesn't (presumably some other module pulling the e-stop\ bus low)
it stays in e-stop. If it rises above the threshold, then the E-stop FF
stays in the OK condition only as long as all the fault conditions stay
in the no-fault state. All motion and auxilliary outputs are gated by
E-stop. So, at most, one step could come out during the attempt to
come out of estop that failed. It would be so narrow that a step motor
driver would not accept it. Also, most of these systems actually power
the step driver down with relays or a FET power ramp circuit with a
time constant of .1 second. So, the drives won't be powered up unless
they get a solid not-estop signal for a sizable part of a second.
Jon
--------------070006050206060905080304
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<br>
<br>
Hal Murray wrote:<br>
<blockquote type="cite" cite="midqtmdnQHnV5abu57fRVn-ug@megapath.net">
<blockquote type="cite">
<pre wrap="">Another is a safety-related reset, perhaps in a motion control system,
where you
need the reset to halt motion and cause an emergency stop, even if the
clock were
to fail. I have something like this in some of my designs. The
external, analog-based
one-shot watchdog timer will cause an e-stop even if the clock to the
FPGA has
gone static. I don't have any problem with an asynchronous release of
this reset,
in this case. it could cause a problem with a simulation, but it won't
cause any
problem in the actual application. The worst case is one more
millisecond before
the e-stop condition ends.
</pre>
</blockquote>
<pre wrap=""><!---->
I missed something. This is a safety critical application. Why
aren't you concerned about coming out of asynchronous resets?
[It's one of my hot buttons. I learned the hard way.]
</pre>
</blockquote>
The way the circuit works, it requires communication from the CPU to<br>
satisfy the watchdog, all other external fault conditions must be clear,
then<br>
the command to come out of emergency stop must be given, and the global<br>
e_stop\ bus signal must rise under resistive pull-up to the logic threshold<br>
DURING the duration of the come out of estop command strobe. If it<br>
doesn't (presumably some other module pulling the e-stop\ bus low)<br>
it stays in e-stop. If it rises above the threshold, then the E-stop FF<br>
stays in the OK condition only as long as all the fault conditions stay<br>
in the no-fault state. All motion and auxilliary outputs are gated by<br>
E-stop. So, at most, one step could come out during the attempt to<br>
come out of estop that failed. It would be so narrow that a step motor<br>
driver would not accept it. Also, most of these systems actually power<br>
the step driver down with relays or a FET power ramp circuit with a<br>
time constant of .1 second. So, the drives won't be powered up unless<br>
they get a solid not-estop signal for a sizable part of a second.<br>
<br>
Jon<br>
</body>
</html>
--------------070006050206060905080304--
Article: 78994Ray, I've used it on V2PRO, and it seemed to work fine. Read up on the "Factory JF" parameter; this has got something to do with the phase update rate. I wonder if your application could take advantage of the DSS mode built into the DCMs. Or did they get rid of that in Spartan3? Cheers, Syms. p.s. Peter, be careful, those delay lines are 'high maintenance'! ;-) "Peter Alfke" wrote > I'm in love with that 64-tap input delay line...Article: 78995
Symon, DSS is gone. Austin Symon wrote: > Ray, > I've used it on V2PRO, and it seemed to work fine. Read up on the "Factory > JF" parameter; this has got something to do with the phase update rate. I > wonder if your application could take advantage of the DSS mode built into > the DCMs. Or did they get rid of that in Spartan3? > Cheers, Syms. > > p.s. Peter, be careful, those delay lines are 'high maintenance'! ;-) > > "Peter Alfke" wrote > >>I'm in love with that 64-tap input delay line... > > >Article: 78996
On Mon, 07 Feb 2005 16:28:45 +0100, Kolja Sulimma <news@sulimma.de> wrote: >Hein Roehrig wrote a detailed description on how to run Impact with >parallel cable on a linux kernel of the 2.6 series. > >I can be found on our server: >http://www.fpga.de/tiki/tiki-index.php?page=XilinxSoftwareLinux > >I also asked philip freidin to upload it to www.fpga-faq.com. > >I Hope this helps, > >Kolja Sulimma This has been added to the FAQ. Thanks to both of you. http://www.fpga-faq.com/FAQ_Pages/0044_Xilinx_Parallel_on_Linux.htm Philip =================== Philip Freidin philip.freidin@fpga-faq.com Host for WWW.FPGA-FAQ.COMArticle: 78997
Austin Lesea wrote:
Peter, can you get me Virtex4 for under $12? If so, I'll gladly use
that instead. Target device is a spartan3-50 for cost reasons. Syms,
as Austin noted, DSS is not in S3. Clock looks like it will be about
100 MHz, and I'll be bumping the phase up by a quarter cycle in 64
increments. Will be using the 0 and 90 clk outs, both edges to get
measurements in each phase quadrant to keep the number of measurements
reasonable. (Simulation works fine on it, so as long as the simulation
matches the hardware, it will be OK). Thanks.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 78998Hi, We are using RocketIO (1GHz Fibre Channel) in 32-bit mode in a Virtex-II Pro 50. We are using the CUSTOM_GT and believe that all the attributes are set correctly. The problem we are having is in our simulations. When data is received it seams that the Comma character is mis-aligned. According to the documention, this can happen and the signal RXREALIGN will indicate when re-alignment of the data is necessary. However, we never see RXREALIGN go high in our simulations. Anyone had similar problems or got any ideas... Thanks, JeffArticle: 78999
>so for the above task I need to connect an external board which > has USB, gigabyte ethernet and firewire ports(PHY) to ML310 > board through its expansion slots such that they have an > direct interaction to main core. >I dont want to the ports on ml310 as they are connected > through PCI bus. What sort of monitoring do you want to do? Why not watch the PCI bus inside the FPGA? Each device will respond to a range of addresses when the CPU talks to it. You can probably figure out which device is generating DMA requests from the request/grant signals. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.
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