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
Davy wrote: > Hi, rickman, > > Thanks! > > Can you tell me what's Nonpipelined bus mean? For non-pipelined bus, all master requests interleave with slave responses: Req - Resp - Req - Resp ..... In pipelined bus, master may send 1<=N<=PD requests in sequence, while receiving responses later: Req1 - Req2 - Req3 - Req4 - Resp1 - Resp2 - Resp3 - Resp4 .... PD is a pipeline depth of the bus. -AlexArticle: 112526
Hi Alex, Thanks a lot! So "non-pipelined bus" is equal to "blocking transaction", Req must need Resp return and send another Req. And likewise, "pipelined bus" is equal to "non-blocking transaction". Is it right? And I think "pipelined bus" may be more complex:-) Best regards, Davy Alex wrote: > Davy wrote: > > Hi, rickman, > > > > Thanks! > > > > Can you tell me what's Nonpipelined bus mean? > > For non-pipelined bus, all master requests interleave with slave > responses: > Req - Resp - Req - Resp ..... > > In pipelined bus, master may send 1<=N<=PD requests in sequence, while > receiving responses later: > Req1 - Req2 - Req3 - Req4 - Resp1 - Resp2 - Resp3 - Resp4 .... > > PD is a pipeline depth of the bus. > > -AlexArticle: 112527
Hi, Could anybody tell me whether any manufacturer of FPGAs provide onchip ADC ? Regards jayArticle: 112528
"Jay" <jaycp.iitkgp@gmail.com> schrieb im Newsbeitrag news:1164349703.836575.3910@l12g2000cwl.googlegroups.com... > Hi, > > Could anybody tell me whether any manufacturer of FPGAs provide onchip > ADC ? > > Regards > jay > Actel Fusion Virtex-5 Stratix-3 (only for onchip temp measurement) AnttiArticle: 112529
Hello, In order to start working with USB 2.0 data transfers, I used two boards for implementation and cross verification. The boards are: 1. Cy 3618 development board for FX2LP chips which support USB 2.0 transfers 2. FPGA developement kit which houses Cy7C68013A chip with all the connections to the FPGA. (By all connections I mean the ones which matter, as we will see later in the post) You will also require "Ez-Usb Control Panel" application from Cypress as well as "Ez Usb development kit" which after installation will create a "Cypress\usb\" folder in the root directory, if you install in the default location. The important folders are: A.1. Cypress\usb\Drivers which contain a generic driver in the root named ezusbw2k.inf A.2. Cypress\usb\Target\Lib\LP folder which contain Ezusb.lib and USBJmpTb.a51 to be used while programming with Keil tools (if you have FX2 or EzUSB development board, then use the respective folders, I am using FX2LP so I am using LP folder). A.3. Cypress\usb\Target\Inc which includes fx2.h, fx2regs.h, syncdly.h for FX2 based boards, otherwise there are ezregs.h, ezusb.h for the development board and kit. A.4. Cypress\usb\Examples which contain respective examples for FX2/FX2LP/EzUSB/FX1/SX2 chips, whichever are applicable in your case. Since I had the facility of development board (EzUSB) I first worked on it to get the board working and loading the hex file (or programming the FX2LP chip on the EzUSB developement board) using both the Keil debugger and the EzUSB Control Panel. I followed the following steps and got the same working responce for identical hex file using both Keil downloading and EzUSB Control Panel: 1. Select no EEPROM on the board by bringing the toggle switch (SW2) down. 2. Plug in the USB device. 3. Open "Windows Control Panel" and from there Systems/hardware/device manager. Check to see if after connecting your board, the "Universal Serial Bus controllers" heading contains "Cypress EzUSB FX2 (68613) - EEPROM Missing" field. If it doesnt and its the first time, the system has started on your computer, then you need to load the driver as explained in bullet A.1. 4. Run EzUSB Control Panel. 5. Open Page 10 of "Ez USB contents and tutorial" which is accessible from the help menu of Ez USB Control Panel and follow instructions until the end of page 13. 6. After successful tutorial completion, disconnect device and close control panel. 7. Select EEPROM Enable on the Ez USB development board (SW2 in upward position), also make sure that the SW1 named "EEPROM Select" is indicating small EEPROM option. 8. Re-Connect the USB cable or device and check from device manager that now it should automatically load the driver but this time its stating "Ez-USB advanced Development Board FX2LP(Keil Monitor)". 9. A green LED should turn on the board (D7) indicating the monitor has been uploaded on to the FX2 chip. 10. Continue following the tutorial "Ez-USB contents and tutorial" from page 14 onwards until you reach page 19. By now you will have established the following: 1. Any hex file provided by the vendor or generated can be downloaded onto FX2 chip using Ez USB control Panel 2. The same hex file can be used for monitoring and debugging the application by using Keil Monitor. An EzUSB chip connected with the FPGA is in the same situation of "Cypress EzUSB FX2 (68613) - EEPROM Missing". Hence, if you write some code and generate the hex file you can download it onto FX2 chip of the FPGA board using EzUSB Control Panel. Then you can program the FPGA with bit file and you will successfully interface the two. There is one small catch, you have to make sure that the FGPA is not resetting the USB which is active low (or depends upon your hardware, you have to check the schematic). So whatever your code in your FPGA, it must always include the reset pin pulled high to ensure that the FPGA doesnt reset your FX2 chip. By default the FX2 chip has CLKOUT pin enabled and it is running at 12 MHz. The first experiment could be to interface the CLKOUT pin, bring it to FPGA and output the same on a general purpose header to be confirmed with an oscilloscope. When you see the 12MHz pulse, x. you will reset the FPGA, y. reporgram the FX2 chip with a difference setting of CPUCS = 0x12 or 0x0A for 48MHz/24MHz respectively, z. download the bit file onto FPGA again, and see the outputs there. If you can, then your FPGA is not resetting the FX2 and your keil hex file generation and hex file downloading will be established. So now, you can write FX2 specific codes for addressing USB modes and endpoints etc. and write a master/slave FIFO or GPIF compatible interface on the FPGA for data communication. We will get to that in a while... I hope it helps... Regards. Mansoor NaseerArticle: 112530
What are types of FPGA like antifuse ,sram based.what is difference under what category cyclone cyclone II device fall thanking youArticle: 112531
hi all we have implemented a picoblaze in vertex 4 kit and we r in the path of implementing JTAG loader to reconfigure block rom ,which is used to change the program ROM. any one have an idea on implementing JTAg loader in VERTEX 4. we tried but it is giving a error of " virtex 2 boundary scan failed to match for virtex 4"" please help us to overcome this problem thanks umeshaArticle: 112532
umeshmgowda@gmail.com schrieb: > hi all > > we have implemented a picoblaze in vertex 4 kit and we r in the path > of implementing JTAG loader to reconfigure block rom ,which is used to > change the program ROM. > any one have an idea on implementing JTAg loader in VERTEX 4. we tried > but it is giving a error of > > " virtex 2 boundary scan failed to match for virtex 4"" > > please help us to overcome this problem > > thanks > umesha take the original picoblaze jtag loader and just replace the bscan primitive then it will work AnttiArticle: 112533
Thanks for your answer Tim, anyway I have found problem: if you want to use C++ and also use the "new" keyword the system must have some HEAP memory to allocate your "new" instance of objects. Now in standard mode the compiler/linker use HEAP=0x0 (STACK=0x400) and so the program did crash with no HEAP instanced. In the compiling/linking option adding -Wl, defsym -Wl,_HEAP_SIZE=0x400 now I can use program with no problem at all. What is very strange is that with a previous version of EDK (8.1) this procedure was not necessary. Anyway I thimk is correct now. Moreovere what it is strange is that implementing an if (... = NULL) to check if the new instruction has been executed well (Ok pointer for the new object) nothing happen because system crash immediately after "new" instruction. Off course this happen if HEAP size is 0. Cheers, AlfmykArticle: 112534
you need to change the BSCAN primitive... and remember to use the picoblaze C compiler! Next Monday you can download the new version 1.8.3 + optimizer!! good luck, Francesco umeshmgowda@gmail.com wrote: > hi all > > we have implemented a picoblaze in vertex 4 kit and we r in the path > of implementing JTAG loader to reconfigure block rom ,which is used to > change the program ROM. > any one have an idea on implementing JTAg loader in VERTEX 4. we tried > but it is giving a error of > > " virtex 2 boundary scan failed to match for virtex 4"" > > please help us to overcome this problem > > thanks > umeshaArticle: 112535
you need to change the BSCAN primitive... and remember to use the picoblaze C compiler! you can download for free on www.poderico.co.uk (do not dowanload the version 1.7.7 is too old.... this evening or tomorrow I'll put the new version 1.8.3) This version has an optimizer (reduce 15% of the code) good luck, Francesco umeshmgowda@gmail.com wrote: > hi all > > we have implemented a picoblaze in vertex 4 kit and we r in the path > of implementing JTAG loader to reconfigure block rom ,which is used to > change the program ROM. > any one have an idea on implementing JTAg loader in VERTEX 4. we tried > but it is giving a error of > > " virtex 2 boundary scan failed to match for virtex 4"" > > please help us to overcome this problem > > thanks > umeshaArticle: 112536
Is it essential to connect the unused OE and GCLR-Pins of an Altera MAX3000A to ground??? the Quartus Pin-file shows GND+ for this pins, with the following meaning of GND+: -- GND+ : Unused input pin. It can also be used to report unused dual-purpose pins. -- This pin should be connected to GND. It may also be connected to a -- valid signal on the board (low, high, or toggling) if that signal -- is required for a different revision of the design. Can I turn on/off the usage of this OE-Pins somewhere in Quartus or where can I see the usage??? Thanks, ManfredArticle: 112537
On Thu, 23 Nov 2006 22:58:47 GMT, "Homer J Simpson" <nobody@nowhere.com> wrote: > >"John Fields" <jfields@austininstruments.com> wrote in message >news:ph5cm2lv6pguo2rlnnqnc1q0pievcv5cgk@4ax.com... > >> Well, there ya go! That's not too bad, actually, considering that >> before I took on the job of teaching you how not to walk on your >> knuckles you were mostly interested in where your next banana was >> coming from. > >You seem to have a fixation about where YOUR next banana will be inserted. --- Not me... Mine will be sliced up, placed on some Cheerios and milk and inserted into my alimentary system at the mouth end. Yours, I'm sure, will remain whole and enter your system from the opposite end. -- JFArticle: 112538
John_H wrote: > Andrew Holme wrote: > > "John_H" <newsgroup@johnhandwork.com> wrote in message > > news:hSn9h.6231$J5.2710@trnddc04... > >> Andrew Holme wrote: > >>> Tool = ISE 8.2i > >>> Target = Spartan 3 xc3s400-4tq144 > >>> > >>> I'm using an external 50 MHz oscillator and a single DCM to generate > >>> clocks of 50, 100 and 200 MHz. The static timing reports says the > >>> minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare. > >>> > >>> I saw this comment in the Verilog file auto-generated by the DCM > >>> wizard: > >>> > >>> // Period Jitter (unit interval) for block DCM_INST = 0.14 UI > >>> // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns > >>> > >>> What does this mean? How can I meet timing by 1ps when the jitter is > >>> 700ps? > >> Austin didn't directly address the DCM-generated jitter. > >> > >> There has been information on the Xilinx tools that suggest that jitter > >> from the DCMs - assuming the input jitter is clean (within datasheet spec) > >> to those devices - is included in the timing analysis. The caveat I saw > >> was something like "for thoroughly characterized Xilinx devices such as > >> the Virtex-4 family" or similar qualification targeting the DCM jitter. > >> > >> I do not know if the tools do, indeed, add the jitter into the timing > >> uncertainty. I haven't looked hard for it but perhaps I should look > >> harder. The caveat left me with a poor feeling about the tools' ability > >> to deal with my Spartan3(E) designs because I don't know if those families > >> were "thoroughly characterized" or not. > >> > >> I'd suggest looking at the full timing report for a 200 MHz path and for a > >> 50 MHz path. Do both have identical Tco and Tsu times? Is there a "clock > >> uncertainty" value used in the slack calculation? > >> > >> The assumption here is that you have a low jitter clock presented to your > >> system for the DCMs to work from. If your input jitter isn't clean, that > >> value needs to be added to your UCF. If it is clean, it was my > >> understanding that the tools were supposed to automatically propagate the > >> DCM jitter values to the registers in that clock domain. > >> > >> Are we there? With all recent families? With some? > > > > I generated a verbose timing report, as you suggested, and every single path > > included the line: > > > > Clock Uncertainty: 0.000ns > > > > So I don't think the DCM jitter is automatically propogated. > > > > If the tools stop trying as soon as they get 1ps of slack, how is it > > supposed to work? Am I supposed to manually create a jitter constraint for > > the DCM? > > You can specify JITTER and/or INPUT_JITTER in the constraints file; > check your constraints guide for details. > > If the "Clock Uncertainty" is where the jitter shows up, then yes - you > would need to add the jitter values manually. I had thought, however, > that the adjustments for DCM generated jitter showed up in a different > form for those families where DCM jitter *is* included such as for the > Tco or Tsu times. If those values match picosecond for picosecond, then > you have no DCM jitter included through those values In the verbose timing report, Tcko is the same for both DCM-generated clocks (0.72ns for setup paths and 0.576ns for hold paths). So I am still confused. Doesn't that mean the place and route stops trying too early?Article: 112539
Hi, Another variety of pipelined buses, is split bus, where the responses can come in out-of-order fashion. Request and Responses are associated with their identification numbers. the transactions can be as follows req1, req2, req3,req4,........ ........req3,req1,req4,req2 1. When the response times are different for different devices, this bus is useful. 2. When there is definite advantage in re-ordering requests, it is useful. for example request scheduling in SDRAMs. -SaiArticle: 112540
Andrew Holme wrote: > John_H wrote: > > Andrew Holme wrote: > > > "John_H" <newsgroup@johnhandwork.com> wrote in message > > > news:hSn9h.6231$J5.2710@trnddc04... > > >> Andrew Holme wrote: > > >>> Tool = ISE 8.2i > > >>> Target = Spartan 3 xc3s400-4tq144 > > >>> > > >>> I'm using an external 50 MHz oscillator and a single DCM to generate > > >>> clocks of 50, 100 and 200 MHz. The static timing reports says the > > >>> minimum period for my 200 MHz clock is 4.999ns i.e. 1ps to spare. > > >>> > > >>> I saw this comment in the Verilog file auto-generated by the DCM > > >>> wizard: > > >>> > > >>> // Period Jitter (unit interval) for block DCM_INST = 0.14 UI > > >>> // Period Jitter (Peak-to-Peak) for block DCM_INST = 0.70 ns > > >>> > > >>> What does this mean? How can I meet timing by 1ps when the jitter is > > >>> 700ps? > > >> Austin didn't directly address the DCM-generated jitter. > > >> > > >> There has been information on the Xilinx tools that suggest that jitter > > >> from the DCMs - assuming the input jitter is clean (within datasheet spec) > > >> to those devices - is included in the timing analysis. The caveat I saw > > >> was something like "for thoroughly characterized Xilinx devices such as > > >> the Virtex-4 family" or similar qualification targeting the DCM jitter. > > >> > > >> I do not know if the tools do, indeed, add the jitter into the timing > > >> uncertainty. I haven't looked hard for it but perhaps I should look > > >> harder. The caveat left me with a poor feeling about the tools' ability > > >> to deal with my Spartan3(E) designs because I don't know if those families > > >> were "thoroughly characterized" or not. > > >> > > >> I'd suggest looking at the full timing report for a 200 MHz path and for a > > >> 50 MHz path. Do both have identical Tco and Tsu times? Is there a "clock > > >> uncertainty" value used in the slack calculation? > > >> > > >> The assumption here is that you have a low jitter clock presented to your > > >> system for the DCMs to work from. If your input jitter isn't clean, that > > >> value needs to be added to your UCF. If it is clean, it was my > > >> understanding that the tools were supposed to automatically propagate the > > >> DCM jitter values to the registers in that clock domain. > > >> > > >> Are we there? With all recent families? With some? > > > > > > I generated a verbose timing report, as you suggested, and every single path > > > included the line: > > > > > > Clock Uncertainty: 0.000ns > > > > > > So I don't think the DCM jitter is automatically propogated. > > > > > > If the tools stop trying as soon as they get 1ps of slack, how is it > > > supposed to work? Am I supposed to manually create a jitter constraint for > > > the DCM? > > > > You can specify JITTER and/or INPUT_JITTER in the constraints file; > > check your constraints guide for details. > > > > If the "Clock Uncertainty" is where the jitter shows up, then yes - you > > would need to add the jitter values manually. I had thought, however, > > that the adjustments for DCM generated jitter showed up in a different > > form for those families where DCM jitter *is* included such as for the > > Tco or Tsu times. If those values match picosecond for picosecond, then > > you have no DCM jitter included through those values > > In the verbose timing report, Tcko is the same for both DCM-generated > clocks (0.72ns for setup paths and 0.576ns for hold paths). So I am > still confused. Doesn't that mean the place and route stops trying too > early? I've taken the pk-pk DCM jitter (0.8ns) and specified it as INPUT_JITTER on my input clock. This now appears as clock_uncertainty = 0.400ns in the timing reports. and my design now fails to meet its constraints.Article: 112541
Hello, I have defined some signals which I plan to change dinamicaly with MicroBlaze as submodule. Signals are organized as arrays and I will use one index and one data port to access them (like PicoBlaze IO ports). What is the best way of interfacing these signals between the MicroBlaze and the top level?Article: 112542
John Fields wrote: > On Wed, 22 Nov 2006 20:28:11 GMT, "Homer J Simpson" > <nobody@nowhere.com> wrote: > >> >>"PeteS" <peter.smith8380@ntlworld.com> wrote in message >>news:Xr19h.59126$r4.34900@newsfe3-gui.ntli.net... >> >>> That's one of the laws of software: >>> >>> All programs expand to consume all available resources >>> >>> I remember implementing a RAM test in 34 bytes, and a 16x16 integer >>> multiply in < 50 bytes. >> >>I once wrote an Eratosthenes' prime number sieve using the video display >>as an array memory (on a 4K machine). > > --- > How high did it go? to 9? > > reserving about 1/4 of that for the program it should be able to go somewhere past 10,000 but not beyond 25,000. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --SchillerArticle: 112543
Hi all, I always found people like to add default branch like below: case(branch) ... ... [all the possible branch] ... ... default: signal = 8'bx; And my friend told me it's for simulation cause. When branch not hit all the possible case, the branch must have something like xxxx. So we set signal to xxxx to let xxxx pass go on and help us to find the bug. If I set default: signal = 0; the xxxx problem will be hidden and hard to find the bug. But as we know, there is no xxxx signal in real digital world. So is there any better method to solve the problem? Best regards, DavyArticle: 112544
Andrew, What version of software are you using? If you read the link: http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?iLanguageID=1&category=&sGlobalNavPick=&sSecondaryNavPick=&multPartNum=1&sTechX_ID=al_slack you would see that 1/2 the total system jitter is what should be your slack (at least), or shortening your clock constraint by 1/2 your p-p system jitter. This answer record details how uncertainty is dealt with by the tool: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=23710 AustinArticle: 112545
http://direct.xilinx.com/bvdocs/userguides/ug192.pdf details the 16 channel A/D in Virtex 5, and all of its use modes. AustinArticle: 112546
ram <vsrpkumar@rediffmail.com> wrote: > What are types of FPGA > like antifuse ,sram based.what is difference > under what category cyclone cyclone II device fall > thanking you Why do you want to know it? What did you do to find out yourself? What kept you from succeeding to find that information? Thank you -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 112547
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Davy wrote: > Hi all, > > I always found people like to add default branch like below: > case(branch) > ... ... > [all the possible branch] > ... ... > default: signal = 8'bx; > > And my friend told me it's for simulation cause. When branch not hit > all the possible case, the branch must have something like xxxx. So we > set signal to xxxx to let xxxx pass go on and help us to find the bug. Your friend talks sense. > If I set default: signal = 0; the xxxx problem will be hidden and hard > to find the bug. Yes. > But as we know, there is no xxxx signal in real digital world. So is > there any better method to solve the problem? That es exactly the point. If your simulation starts showing xxx values for signals, that should be a clue that your design has a problem that should be fixed even before you try to synthesize it. That xxxx does not show up in real logic is exactly the point! It's saying "Hey look here! Something happened that you don't want in your real hardware!" - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFZyYrrPt1Sc2b3ikRAvqUAKCm4njVxE4S8R2godBfpwIyCfui+ACeJyQY o7U37cy4P+PUIbDWQvIkgKo= =9sa1 -----END PGP SIGNATURE-----Article: 112548
Davy wrote: > Hi all, > > I always found people like to add default branch like below: > case(branch) > ... ... > [all the possible branch] > ... ... > default: signal = 8'bx; > > And my friend told me it's for simulation cause. When branch not hit > all the possible case, the branch must have something like xxxx. So we > set signal to xxxx to let xxxx pass go on and help us to find the bug. > > If I set default: signal = 0; the xxxx problem will be hidden and hard > to find the bug. > > But as we know, there is no xxxx signal in real digital world. So is > there any better method to solve the problem? What is the problem with this? It does not matter that this doesn't correspond to a real world value. The synthesis tool will see that it is a don't care, and hopefully should optimise the logic accordingly, giving you the smallest / fastest circuit. Cheers, JonArticle: 112549
"John Fields" <jfields@austininstruments.com> wrote in message news:9ijdm2t4l2ee5cik1vlhhotrh9m6v3l6aj@4ax.com... >>You seem to have a fixation about where YOUR next banana will be inserted. > Not me.. And yet you constantly make comments about other people being gay, comments based solely on your own fixations. Based on experience?
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