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
On 3/19/2010 5:56 PM, HT-Lab wrote: > > Depending on what you want to do with the core but I would suggest you also have > a look at the Amba bus since (thanks to Gaisler research?) this bus seems to be > gaining popularity amonst the space/mil-aero users. > Indeed I was trying to understand the main differences just because I know that there are IP cores available which are interfaced with AMBA, but the main idea behind is to have a copyleft license on the core, mainly to share it in the academic community, especially for those science projects which are space related. Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 146476
We have just completed a design using the GN4124. It's a HDMI capture card for 1080p video. It's working very well, but we had to do some driver fixes to increase stability. The FPGA IP is working great. We easily added a scaler and a few other tricks. We are currently looking into converting the driver to Linux. Gilles Chouinard Dextera Labs gilles@dexteralabs.com >> >>Anyone had any experiences with the GN4124? Or alternatively, with the >>PEX8311 by PLX, which is the only other chip I've managed to find that >>performs a similair task? The ultimate project goal is going to be a >>PCIe card with an FPGA talking to a mini-ITX running Linux, and I'm >>likely going to be the one doing the coding on all ends. Total project >>run's only likely about 200, 250 pieces, so it's easier to spend BOM >>money than it is to buy expensive IP or spend weeks and weeks of extra >>coding. >> >>-- >>Rob Gaddi, Highland Technology >>Email address is currently out of order >> >I'm currently looking for a way around the PLX PEX8311 device's limitations >so I wouldn't recommend using it. The PEX8311 is really a two die chip >with a PEX81111 and a PCI9056. The PEX8111 does not support MSI interrupts >(which I've been requested to add to our product) and none of PLX's PCI >devices support MSI. Before you use the PEX8311 download the errata sheets >on the 8311, the 8111, and the 9056; they all apply to the 8311. > >I've used the PCI9080, PCI9656, PCI9054, and PEX8311 on various boards. So >long as an errata doesn't get in your way they're not bad chips. > >I'm looking at either trying to create my own PCI to local bus interface >with an FPGA or using something like the GN4124 or the AAE-B04 (looks like >it's made by Daitron). > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146477
Hi all, There's an instance of BRAM in spartan3 device. I used coregen with *.coe file to init the data for the memory module My question, is there anyway to edit the mcs file (we use flatform flash for config) to change the content of init data ..."without spend 20 minutes to re-run the whole ISE processes Thanks,Article: 146478
On Mar 19, 3:01=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > Hi all, > > There's an instance of BRAM in spartan3 device. =A0I used coregen with > *.coe file to init the data for the memory module > > My question, is there anyway to edit the mcs file (we use flatform > flash for config) to change the content of init data ..."without spend > 20 minutes to re-run the whole ISE processes > > Thanks, "There's an app for that." http://www.xilinx.com/products/ipcenter/dr_dt_data2mem.htmArticle: 146479
On Mar 19, 2:17=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 19, 3:01=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > Hi all, > > > There's an instance of BRAM in spartan3 device. =A0I used coregen with > > *.coe file to init the data for the memory module > > > My question, is there anyway to edit the mcs file (we use flatform > > flash for config) to change the content of init data ..."without spend > > 20 minutes to re-run the whole ISE processes > > > Thanks, > > "There's an app for that." > > http://www.xilinx.com/products/ipcenter/dr_dt_data2mem.htm Thanks for the link, I do search around and all route to that page.. But I'm not sure I can get anything, Is there any download-able thing ? ThanksArticle: 146480
Am Fri, 19 Mar 2010 17:00:09 -0000 schrieb HT-Lab: > "Thorsten Kiefer" <info@tokis-edv-service.de> wrote in message > news:17niij03a6nx9.1h1jj0j0b8jgk.dlg@40tude.net... >> Hi, >> I wrote a small example for the Digilent Spartan 3 Starter Kit. >> It uses the sram to store graphics data. >> Actually basing on this module I wanted to code a fractal generator. >> Here is the link, maybe someone finds it useful : >> http://tokis-edv-service.de/index.php/beispiele/spartan-3-example-1 > > Why would anybody find this useful? You only provide a bit file for one > particular prototype board. I would add the code or at least add some comments > on the lessons learned writing for this board. > > Hans > www.ht-lab.com > > >> The last test is a rather long time ago. >> >> Best Regards >> Thorsten Right it's not too useful. I'll provide the code I coded myself. But I cannot provide the source code, that I took from the book. Thanks for the comment ! ThorstenArticle: 146481
Am Fri, 19 Mar 2010 21:06:04 +0100 schrieb Thorsten Kiefer: > Am Fri, 19 Mar 2010 17:00:09 -0000 schrieb HT-Lab: > >> "Thorsten Kiefer" <info@tokis-edv-service.de> wrote in message >> news:17niij03a6nx9.1h1jj0j0b8jgk.dlg@40tude.net... >>> Hi, >>> I wrote a small example for the Digilent Spartan 3 Starter Kit. >>> It uses the sram to store graphics data. >>> Actually basing on this module I wanted to code a fractal generator. >>> Here is the link, maybe someone finds it useful : >>> http://tokis-edv-service.de/index.php/beispiele/spartan-3-example-1 >> >> Why would anybody find this useful? You only provide a bit file for one >> particular prototype board. I would add the code or at least add some comments >> on the lessons learned writing for this board. >> >> Hans >> www.ht-lab.com >> >> >>> The last test is a rather long time ago. >>> >>> Best Regards >>> Thorsten > > Right it's not too useful. I'll provide the code I coded myself. > But I cannot provide the source code, that I took from the book. > Thanks for the comment ! > > Thorsten I added 2 files of source now. Is it more useful now ? ThorstenArticle: 146482
On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote: [Weng] >> there are 6 types of >> reset signals, a situation much more complexer than we think. >Ok, go ahead and tease us! Or are you going to share with us what the >six types are? 1. Reset that is asserted at the right time, but has the wrong polarity, thus holding the design in reset throughout your test. 2. Reset with the right polarity that is not asserted reliably at power-up, because you were too cheap to spend $0.70 on a power monitor/watchdog chip. 3. Reset that is triggered at random times during operation because it is laid out on the PCB too close to a data bus. Capacitive coupling causes reset to be momentarily asserted when more than 80% of the data lines transition simultaneously. 4. Reset that is asserted correctly, but is released too close to a clock edge and causes the design to go into an illegal state because some flops respond to the clock and others don't. 5. Reset of a counter, used by a designer who thought it would be a cool way to make the counter go back to zero when it overflows some programmed limit. 6. Reset that is triggered by the operation of a system-level watchdog. It causes the CPU to stop operating roughly a millisecond before emitting the debug message that would have allowed you to diagnose the problem. Just in case you thought I was fooling, I should point out that I have had to debug and correct each of these at some point in my career. One or two of them were someone else's fault :-) -- Jonathan BromleyArticle: 146483
On Mar 17, 4:09=A0pm, Aditi <aditi...@gmail.com> wrote: > Hi all, > > I am working on a new design and have chosen the Spartan 6 family FPGA > for it. I was looking to see if there is a an on-chip PROM on any of > the Spartan 6 FPGAs. I could not find about it in the datasheet. But > if there is something that I am missing or if there is any other > series of FPGAs with on-chip PROM, do let me know. > > Thank you, > Aditi Akula. Depending on what you need in your design, the Spartan-3AN (N=3DNonvolatile) family may meet your needs. However, Spartan-3AN does not have an integrated memory controller nor does it have gigabit transceivers available in some Spartan-6 FPGAs. Spartan-3AN FPGAs are single-chip with integrated on-chip Flash memory, large enough for FPGA configuration plus extra. Spartan-3AN FPGA Family http://www.xilinx.com/products/spartan3a/3an.htm There are others as well, depending on your needs including Actel Igloo and ProASIC and SiliconBlue iCE65 FPGAs. It all depends on your requirements. -- Steve Knapp Prevailing Technology, Inc. www.prevailing-technology.comArticle: 146484
On Wed, 17 Mar 2010 16:09:36 -0700 (PDT) Aditi <aditimis@gmail.com> wrote: > Hi all, > > I am working on a new design and have chosen the Spartan 6 family FPGA > for it. I was looking to see if there is a an on-chip PROM on any of > the Spartan 6 FPGAs. I could not find about it in the datasheet. But > if there is something that I am missing or if there is any other > series of FPGAs with on-chip PROM, do let me know. > > Thank you, > Aditi Akula. Or for less than $2 you can get an SPI flash of whatever size you'd like in a TSSOP-8 or smaller package and not restrict your FPGA choice. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146485
On Mar 19, 9:56=A0am, "HT-Lab" <han...@ht-lab.com> wrote: > > Depending on what you want to do with the core but I would suggest you al= so have > a look at the Amba bus since (thanks to Gaisler research?) this bus seems= to be > gaining popularity amonst the space/mil-aero users. > > Hanswww.ht-lab.com > I have an objection to the AMBA bus. Namely: "This document is only available in a PDF version to registered ARM customers." Yuck.Article: 146486
On Mar 17, 8:30=A0am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > What's special about 45 nm? Is it just the sheer increase in chip > complexity that breaks the tools? The development software just sees > CLBs. > > John Hey John (et all), One of the things that is "special" about 45nM is that routing delays are now massively more significant than gate delays. If you map for 'area', you will probably get a faster par than if you map for 'speed'. Having the logic closer together reduces wire delays, and when wire delays are 80% of the net delay... I'm sure that they will figure it out. Eventually. ALArticle: 146487
On Mar 19, 2:31=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Fri, 19 Mar 2010 06:32:38 -0700 (PDT), rickman wrote: > > [Weng] > > >> there are 6 types of > >> reset signals, a situation much more complexer than we think. > >Ok, go ahead and tease us! =A0Or are you going to share with us what the > >six types are? > > 1. Reset that is asserted at the right time, > =A0 =A0but has the wrong polarity, thus holding the design > =A0 =A0in reset throughout your test. > 2. Reset with the right polarity that is not asserted > =A0 =A0reliably at power-up, because you were too cheap > =A0 =A0to spend $0.70 on a power monitor/watchdog chip. > 3. Reset that is triggered at random times during > =A0 =A0operation because it is laid out on the PCB too > =A0 =A0close to a data bus. =A0Capacitive coupling causes > =A0 =A0reset to be momentarily asserted when more than > =A0 =A080% of the data lines transition simultaneously. > 4. Reset that is asserted correctly, but is released > =A0 =A0too close to a clock edge and causes the design > =A0 =A0to go into an illegal state because some flops > =A0 =A0respond to the clock and others don't. > 5. Reset of a counter, used by a designer who thought > =A0 =A0it would be a cool way to make the counter go back > =A0 =A0to zero when it overflows some programmed limit. > 6. Reset that is triggered by the operation of a > =A0 =A0system-level watchdog. =A0It causes the CPU to stop > =A0 =A0operating roughly a millisecond before emitting > =A0 =A0the debug message that would have allowed you > =A0 =A0to diagnose the problem. > > Just in case you thought I was fooling, I should point > out that I have had to debug and correct each of these > at some point in my career. =A0One or two of them were > someone else's fault :-) > -- > Jonathan Bromley Hi, Here is where you can find the contents: http://www.opensparc.net/opensparc-t2/download.html 1. /doc/OpenSPARCT2_SoC_Micro_Arch_Vol1.pdf 2. /doc/OpenSPARCT2_SoC_Micro_Arch_Vol2.pdf 3. There are too many reset descriptions. I just copy the most important context here. 2.2.2 Reset Sequence for L2 cache In L2 cache, parity bits in the tag array, valid bits in VUAD array and the directories should be initialized before L2 cache is enabled to guarantee coherency and correct functionality. The directory valid bits are cleared with flash reset during POR_. The reset block drives the flash reset. When the valid bits are cleared (not valid) then the entries are don=92t care. Hence, the parity bits are not initialized to good parity. Clearing valid bits in the directory informs the L2 cache that there are no valid lines in L1. BISI or ASIs are used to initialize the VUAD arrays by clearing all the valid bits. This informs L2 cache that there are no valid lines in L2. BISI or ASIs are used to initialize the tag array with good parity. This eliminates the possibility of any error cases from happening. 4.16.6 ASIC Reset The ASIC blocks in OpenSPARC T2 DMU are treated differently from other clusters during the reset sequence and warm or debug resets. During POR1 the DMU has its clocks stopped until the RST unit tells TCU to release them with rst_tcu_asicflush_stop_req; this signal comes earlier than rst_tcu_flush_stop_req. When the asicflush_stop_req is received, TCU releases itself from its own flush reset and turns off the clock stops to the ASICs and deasserts tcu_asic_scan_en. The tcu_asic_aclk is not asserted at all during POR1, preventing a flush state to the ASICs. During subsequent resets (WMR1, WMR2) the ASIC clock stops are allowed to activate in the normal clock stop sequence but the ASICs are not 4-90 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 =95 May 2008 flushed. During debug resets (DBR) the signal rst_tcu_dbr_gen is active and TCU does not activate the clock stops to the ASICs to allow them to continue running. During JTAG clock stop operations, these blocks behave as other SOC blocks. During POR2 the ASIC clock stops will be held deasserted. 5.3.2 Reset Scheme The CCU relies on the RST block for explicit reset signals, and does not operate via flush reset. Also, it needs to be released from reset before all other blocks on the chip. One reset is solely for the PLL, and the other for the remaining CCU logic, loosely speaking. The CCU itself needs to generate one or two staggered resets. These resets work in a domino like fashion to ultimately provide a signal to the RST unit that indicates the CCU is done with initialization, and that the RST block may release the rest of the chip from reset. This signal is ccu_rst_sync_stable. When the signal goes high, all clocks from the CCU are valid, at the correct frequency, and all sync pulses are operating in their proper positions. Depending on whether clocks may be stable or not, the CCU needs to use either asynchronous or synchronous reset. However, all resets within the CCU are released synchronously. Emphasis has been placed on determinism and repeatability, so even where brute-force synchronization is used, additional signals ensure determinism. There is only one CSR register in the CCU that is warm reset protected. All clock generating and pll programmation bits are warm reset protected. The rest are not. 5.3.3 Initialization Sequence The Power-On-Reset scheme in the CCU is highlighted by the waveforms in FIGURE 5-9. For functional operation, the CCU is activated in a very simple manner. There are two resets to the CCU, ccu_rst_pll_ and ccu_rst_ that need to be applied in a sequence. Testmode, and divider_bypass pins need to be held low. Chapter 5 Clock Control Unit (CCU) 5-17 An explanation of the various numbered parameters is given in TABLE 5-5. TABLE 5-5 Key Parameters in Initialization Sequence Parm # Description Duration 1 Time taken for first rising edge of refclk to appear from release of rst_ccu_pll_ <1 sys_clk cycle 2 Deassertion of rst_ccu_pll_ to rising edge of stable CMP PLL clock output LOCK TIME 3 Clock distribution delay of global clock tree from PLL output to gclk input of cluster header ~0.5 =96 ~1.3 CMP cycle 4 Deassertion of rst_ccu_ to gclk_rst_n (requires use of brute force synchronizer) 1 to 2 CMP cycles 5 Rising edge of refclk to assertion of aligned_shift pulse. 3 CMP cycles 6 Shift of aligned_shift pulse to create VCO aligned 4 to 17 CMP cycles depending on pll_div2[5:0] 7 Transfer of aligned signal from CMP PLL domain to CMP_GCLK domain. Tracks parameter #3 8 From first aligned pulse to aligned_rst_n signal for internal CCU blocks for coherent reset release. 1 CMP cycle 9 Deassertion of aligned_rst_n to first rising edge of ccu_io2x_out 2 CMP cycles 10 Deassertion of aligned_rst_n to first rising edge of ccu_io_out 4 CMP cycles 11 Time when aligned =3D=3D 1 to deassertion of divider for generating DR clock within PLL 2-3 CMP cycles depending on pll_div4[6:0] 12 Deassertion of dft_a_rst_l to first rising edge of dr_clk 5-6 CMP cycles depending on pll_div4[6:0] 5-18 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 =95 May 2008 FIGURE 5-7 CCU Clock Domains and Function Chapter 5 Clock Control Unit (CCU) 5-19 FIGURE 5-8 Align Detection Circuitry FIGURE 5-9 Initialization Sequence for CCU Clocks 5-20 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 =95 May 2008 5.4 Sync Pulses The main application of generating synchronization pulses in OpenSPARC T2 is to allow low latency, deterministic data transfer between ratioed synchronous clock domains. The key requirements for this scheme to work are: A single reference clock source. PLLs that have similar behavior, in particular a known input-output phase relationship. The clock frequencies need to be rational multiples of each other, or ratioed synchronous Jitter, skew, and other PVT mismatches are taken into account to ensure setup and hold requirements are met during domain crossing. Clock domains that are of primary concern are the CMP and DR domains. Synchronization between cmp and IO, or IO2X domains is a simpler problem, but handled similarly. 5.4.1 Proposed Scheme The following circuit shows the proposed scheme for clock domain transfers. FIGURE 5-10 CMP to DR Synchronization Chapter 5 Clock Control Unit (CCU) 5-21 FIGURE 5-11 DR to CMP Synchronization It has been borrowed from past designs and modified. All it does is allow data to cross one domain to another during a safe interval, avoiding setup and hold problems. The mechanism for operation for fast clock (e.g., cmp) to slow clock (e.g., dr) domain is as follows: Mux enable to launch flip-flop is generated on cmp_clk. Next cmp rising edge, data is launched. Data is captured on dr_clk. For slow clock to fast clock transfers, the procedure is: Data is launched on rising edge of dr_clk. Mux enable to capture flip-flop is generated on cmp_clk. Next cmp rising edge, data is captured. In both cases, the rate of communication is limited by the slower clock frequency, so the enable is generated once every slow clock cycle. The main challenge is to determine the ideal intervals between pulse generation for robust operation. For a discussion on determining the positions, refer to Appendix A.1 =96 Sync Pulse Design Procedure. 5-22 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 =95 May 2008 5.4.2 Sync Pulse Distribution FIGURE 5-12 Logical Representation of Sync Pulse Global Distribution Sync pulses will be generated in the CCU on the cmp_gclk domain, and be distributed (along with other control signals) in five stages of pipeline in mini-clusters to each cluster header. In the cluster headers, there will be one more stage of latching the data on the gclk domain. From there, each cluster will flop the enables on the l2clk domains before local distribution. In effect, there will be seven stages of cmp_cycle before sync pulses are output from cluster headers, and then flopped one last time within clusters. Chapter 5 Clock Control Unit (CCU) 5-23 5.4.3 CMP to IO/IO2X Waveforms Domain crossing between CMP and IO/IO2X domains is a special, and simpler case of CMP to DR communication because cmp_clk is an integer multiple of io_clk and io2x_clk, and both io_clk and io2x_clk are directly derived from cmp_clk FIGURE 5-13 shows the actual usage, i.e., the final sync_en output (refer to FIGURE 5-9). FIGURE 5-13 Actual Usage of Sync Pulses at Enable Pin of Transfer Flops Note =96 Since cmp_io2x_sync_en and io2x_cmp_sync_en are shown at the point of usage; however, they would both be driven by a single source =96 cluster header->io2x_sync_en ->flop output. 5-24 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 =95 May 2008 For clarity, the outputs of cluster headers are also shown. These are, as expected from FIGURE 5-9, one l2clk cycle early. FIGURE 5-14 Sync Enable Positions at the Outputs of Cluster Headers prior to being latched. 5.4.4 CMP/DR Pulses CMP to DR pulse positions are determined by the amount of uncertainty that can exist between cmp_clk and dr_clks. A discussion on the procedure of determining the positions appears in the AAppendix A.1 =96 Sync Pulse Design Procedure. There Chapter 5 Clock Control Unit (CCU) 5-25 are several documents detailing the sync pulse schemes and timing budgets that have been created to ensure robustness. An example of the positions of the dr sync pulses is shown in FIGURE 5-15. FIGURE 5-15 Sync Pulse Example for fCMP:fDR =3D 11:4 The convention is to describe the sync pulse position in terms of cmp clk phases, with phase 0 being set to the nominal alignment of cmp and dr clocks. The sync pulse positions at the point of domain crossing are given in TABLE 5-6. TABLE 5-6 DR<->CMP Sync Pulse Positions CMP<->DR Transfer Edge Transfer phase (normalized for four dr=3D2pi) K - > clk cycles K - > clk cycles N M Meff N/M 0 1 2 3 0 1 2 3 8 4 1 2.00 1 1 1 1 1 3 5 7 9 4 4 2.25 1 3 6 8 1 3 6 8 10 4 2 2.50 1 4 1 4 1 4 6 9 11 4 4 2.75 1 4 7 10 1 4 7 10 12 4 1 3.00 1 1 1 1 1 4 7 10 13 4 4 3.25 2 5 8 11 2 5 8 11 14 4 2 3.50 2 5 2 5 2 5 9 12 15 4 4 3.75 2 6 9 13 2 6 9 13 16 4 1 4.00 2 2 2 2 2 6 10 14 17 4 4 4.25 2 6 11 15 2 6 11 15 18 4 2 4.50 2 7 2 7 2 7 11 16 5-26 OpenSPARC T2 SoC Microarchitecture Specification Part 1 of 2 =95 May 2008 5.4.5 CMP/SYS Pulses There are a pair of sync pulses between CMP and SYS_CLK strictly for the RST unit. These pulses are not staged on the global clock tree, and not taken in through cluster headers. However, to account for fanout, the signals are flopped twice inside the RST cluster. The scheme relies on the RST block being placed close to the CCU; there is tolerance built in for skew between the CMP and SYS_CLK up to a couple of CMP cycles. The active position of the sync pulse (=931=94 on rising edge of cmp_clk) will be on phase two of l2clk. This will provide ample margin, > 1 fast cmp cycle for setup or hold. Illustrations of data transfers in both directions are shown in FIGURE 5-16. For quantification of the amount of margin available, refer to Appendix A. 1 =96 Sync Pulse Design Procedure. 19 4 4 4.75 2 7 12 17 2 7 12 17 20 4 1 5.00 2 2 2 2 2 7 12 17 21 4 4 5.25 3 8 13 18 3 8 13 18 TABLE 5-6 DR<->CMP Sync Pulse Positions (Continued) CMP<->DR Transfer Edge Transfer phase (normalized for four dr=3D2pi) K - > clk cycles K - > clk cycles Chapter 5 Clock Control Unit (CCU) 5-27 FIGURE 5-16 Domain Crossing using Sync Pulses in RST Reset signals are distributed across all logic digital designs. WengArticle: 146488
On Mar 19, 3:55=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > On Mar 19, 2:17=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > > > > On Mar 19, 3:01=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > > Hi all, > > > > There's an instance of BRAM in spartan3 device. =A0I used coregen wit= h > > > *.coe file to init the data for the memory module > > > > My question, is there anyway to edit the mcs file (we use flatform > > > flash for config) to change the content of init data ..."without spen= d > > > 20 minutes to re-run the whole ISE processes > > > > Thanks, > > > "There's an app for that." > > >http://www.xilinx.com/products/ipcenter/dr_dt_data2mem.htm > > Thanks for the link, I do search around and all route to that page.. > But I'm not sure I can get anything, > Is there any download-able thing ? > > Thanks Have you looked in your Xilinx directories for your installed ISE? >From a random sell sheet: ISE=99 WebPack FPGA Design Tool Suite =95 Timing driven FPGA hardware implementation tools =95 Design entry, synthesis and verification capabilities =95 Data2MEM =96 application for loading on-chip memory It looks like it's included standard.Article: 146489
On Mar 19, 10:05=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > On Mar 19, 3:55=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > > > On Mar 19, 2:17=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > > > On Mar 19, 3:01=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > > > Hi all, > > > > > There's an instance of BRAM in spartan3 device. =A0I used coregen w= ith > > > > *.coe file to init the data for the memory module > > > > > My question, is there anyway to edit the mcs file (we use flatform > > > > flash for config) to change the content of init data ..."without sp= end > > > > 20 minutes to re-run the whole ISE processes > > > > > Thanks, > > > > "There's an app for that." > > > >http://www.xilinx.com/products/ipcenter/dr_dt_data2mem.htm > > > Thanks for the link, I do search around and all route to that page.. > > But I'm not sure I can get anything, > > Is there any download-able thing ? > > > Thanks > > Have you looked in your Xilinx directories for your installed ISE? > > From a random sell sheet: > > ISE=99 WebPack FPGA Design Tool Suite > =95 Timing driven FPGA hardware implementation tools > =95 Design entry, synthesis and verification capabilities > =95 Data2MEM =96 application for loading on-chip memory > > It looks like it's included standard. Yes, I see that execute file data2mem, look like old day command line. Guessing it's just another non-user-friendly Xilnx apps ;-) ThanksArticle: 146490
On 20 Mar, 04:28, Mawa_fugo <cco...@netscape.net> wrote: > On Mar 19, 10:05=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > > > > On Mar 19, 3:55=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > > On Mar 19, 2:17=A0pm, John_H <newsgr...@johnhandwork.com> wrote: > > > > > On Mar 19, 3:01=A0pm, Mawa_fugo <cco...@netscape.net> wrote: > > > > > > Hi all, > > > > > > There's an instance of BRAM in spartan3 device. =A0I used coregen= with > > > > > *.coe file to init the data for the memory module > > > > > > My question, is there anyway to edit the mcs file (we use flatfor= m > > > > > flash for config) to change the content of init data ..."without = spend > > > > > 20 minutes to re-run the whole ISE processes > > > > > > Thanks, > > > > > "There's an app for that." > > > > >http://www.xilinx.com/products/ipcenter/dr_dt_data2mem.htm > > > > Thanks for the link, I do search around and all route to that page.. > > > But I'm not sure I can get anything, > > > Is there any download-able thing ? > > > > Thanks > > > Have you looked in your Xilinx directories for your installed ISE? > > > From a random sell sheet: > > > ISE=99 WebPack FPGA Design Tool Suite > > =95 Timing driven FPGA hardware implementation tools > > =95 Design entry, synthesis and verification capabilities > > =95 Data2MEM =96 application for loading on-chip memory > > > It looks like it's included standard. > > Yes, I see that execute file data2mem, look like old day command > line. =A0Guessing it's just another non-user-friendly Xilnx apps ;-) > > Thanks Console apps are user-friendly matter of who their friends are ;) Some examples should be helpful http://home.mnet-online.de/al/BRAM_Bitstreams.html There is also app for updating picoblaze code through jtag that also could be useful after some modifications. http://forums.xilinx.com/xlnx/board/message?board.id=3DPicoBlaze&message.id= =3D3Article: 146491
It would be nice if they supplied both GUI and command-line tools, but if they're only going to do one or the other, I'd far rather have the command line tool than a GUI tool. I can trivially invoke a command line tool from my software Makefile, but it's a serious PITA to do that with a GUI tool.Article: 146492
"LittleAlex" <alex.louie@email.com> wrote in message news:fc3e6150-3e2b-4e9e-8d99-99078be700d4@n39g2000prj.googlegroups.com... On Mar 19, 9:56 am, "HT-Lab" <han...@ht-lab.com> wrote: > > Depending on what you want to do with the core but I would suggest you also > have > a look at the Amba bus since (thanks to Gaisler research?) this bus seems to > be > gaining popularity amonst the space/mil-aero users. > > Hanswww.ht-lab.com > > >I have an objection to the AMBA bus. Namely: "This document is only >available in a PDF version to registered ARM customers." > >Yuck. There are lots of places were you can legally download it from, if you do a google search (amba bus protocol) then the first entry is wikipedia and the second is: http://ens.ewi.tudelft.nl/Education/courses/et4351/amba.pdf If you read the second page it states: Document confidentiality status This document is Open Access. This document has no restriction on distribution. Hans www.ht-lab.comArticle: 146493
"Thorsten Kiefer" <info@tokis-edv-service.de> wrote in message news:14ezponmgfjcm$.16aouitl2celg$.dlg@40tude.net... > Am Fri, 19 Mar 2010 21:06:04 +0100 schrieb Thorsten Kiefer: > >> Am Fri, 19 Mar 2010 17:00:09 -0000 schrieb HT-Lab: >> >>> "Thorsten Kiefer" <info@tokis-edv-service.de> wrote in message >>> news:17niij03a6nx9.1h1jj0j0b8jgk.dlg@40tude.net... >>>> Hi, >>>> I wrote a small example for the Digilent Spartan 3 Starter Kit. >>>> It uses the sram to store graphics data. >>>> Actually basing on this module I wanted to code a fractal generator. >>>> Here is the link, maybe someone finds it useful : >>>> http://tokis-edv-service.de/index.php/beispiele/spartan-3-example-1 >>> >>> Why would anybody find this useful? You only provide a bit file for one >>> particular prototype board. I would add the code or at least add some >>> comments >>> on the lessons learned writing for this board. >>> >>> Hans >>> www.ht-lab.com >>> >>> >>>> The last test is a rather long time ago. >>>> >>>> Best Regards >>>> Thorsten >> >> Right it's not too useful. I'll provide the code I coded myself. >> But I cannot provide the source code, that I took from the book. >> Thanks for the comment ! >> >> Thorsten > > I added 2 files of source now. > Is it more useful now ? > > Thorsten Much better, however, there shouldn't be a problem listing the code from an educational book provided you acknowledge/credit the author. Hans www.ht-lab.comArticle: 146494
> Does anybody know the reason behind? "This new, single global channel partner model will reduce redundancies within Xilinx distribution operations and is part of Xilinx's ongoing efficiency efforts," said the spokesperson >From http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=223101307 > seems that Xilinx has decided to have only one distributor "The spokesperson said Xilinx would continue to use Digikey" along with Avnet. JonArticle: 146495
On Thu, 18 Mar 2010 12:32:11 -0400, DJ Delorie <dj@delorie.com> wrote: |On 03/18/2010 10:03 AM, Francesco wrote: |> seems that Xilinx has decided to have only one distributor... | |Really? Their authorized distributors page lists two. That will remain so until June. Then Nu H will either have sold their existing stock or will return that stock to Xilinx from what I gather. Also it looks as if Digikey will remain a "regional" partner. I guess Digikeyremains a "partner" due to they will be an outlet for parts and boards and that is all. jamesArticle: 146496
>Hi everyone, >I'm just about to start an implementation of an open spacewire IP core >(still trying to understand under which license, GPL, LGPL, CeCILL...) >and I was wondering whether is a good idea to have a wishbone interface >implemented. >I am pretty new to SoC bus and even though google is "one of my best >friends" I still didn't get the feeling how popular it is and how spread >it is at the moment or will be in the future. >If anyone has any opinion I would be glad to listen to it. >Thanks a lot, > >Al > >-- >Alessandro Basili >CERN, PH/UGC >Hardware Designer > Yes and no, First create your core logic as a "headless" design with no bus interface. Make a testbench that directly drives and tests the ports of this core design. Then create a module with a wishbone interface and connections for all the ports of your core that do not connect to a higher level. Your design will consist of a wrapper containing these two modules. Copy your test suite and rewrite it to use the wishbone bus where needed. DO NOT create a wishbone interface and then place your core logic below it in the hierarchy. If you do and then later want to support a different bus then you are screwed. If you keep the wishbone in one module then it is alot easier to take that module and convert it into something like a AHB bus. You want to be able to add new buses without touching the core. John --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146497
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On Thu, 18 Mar 2010 07:03:38 -0700 (PDT), Francesco ><francescopoderico@googlemail.com> wrote: > >>Hi all, >>seems that Xilinx has decided to have only one distributor... and >>NuHorizons seems out of business. Does anybody know the reason behind? >>I believed was a good idea to have have the opportunity to buy from 2 >>distributors. Interesting move. Where other manufacturers have let go of the single distirbution points Xilinx actually shrinks the number of 'dealers'. >Yup. NuH may have to rif around 200 FAEs. Xilinx was something like >35% of their business. It was apparently a shock to them. > >I suppose this is a good time to hire unemployed FPGA guys... I might >do that. Sure an FAE will make a good engineer? There is a reason some engineers end up in the sales department. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146498
"Francesco" <francescopoderico@googlemail.com> wrote in message news:69b783cf-45c4-4a22-b605-c08c1798d9c5@g26g2000yqn.googlegroups.com... > Hi all, > seems that Xilinx has decided to have only one distributor... and > NuHorizons seems out of business. Does anybody know the reason behind? > I believed was a good idea to have have the opportunity to buy from 2 > distributors. So I just brought an Xilinx Nanoboard 3000... should I send it back while I still can?Article: 146499
On Mar 20, 2:52=A0am, modimo <g.mod...@gmail.com> wrote:
> On 20 Mar, 04:28, Mawa_fugo <cco...@netscape.net> wrote:
>
>
>
> > On Mar 19, 10:05=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > On Mar 19, 3:55=A0pm, Mawa_fugo <cco...@netscape.net> wrote:
>
> > > > On Mar 19, 2:17=A0pm, John_H <newsgr...@johnhandwork.com> wrote:
>
> > > > > On Mar 19, 3:01=A0pm, Mawa_fugo <cco...@netscape.net> wrote:
>
> > > > > > Hi all,
>
> > > > > > There's an instance of BRAM in spartan3 device. =A0I used coreg=
en with
> > > > > > *.coe file to init the data for the memory module
>
> > > > > > My question, is there anyway to edit the mcs file (we use flatf=
orm
> > > > > > flash for config) to change the content of init data ..."withou=
t spend
> > > > > > 20 minutes to re-run the whole ISE processes
>
> > > > > > Thanks,
>
> > > > > "There's an app for that."
>
> > > > >http://www.xilinx.com/products/ipcenter/dr_dt_data2mem.htm
>
> > > > Thanks for the link, I do search around and all route to that page.=
.
> > > > But I'm not sure I can get anything,
> > > > Is there any download-able thing ?
>
> > > > Thanks
>
> > > Have you looked in your Xilinx directories for your installed ISE?
>
> > > From a random sell sheet:
>
> > > ISE=99 WebPack FPGA Design Tool Suite
> > > =95 Timing driven FPGA hardware implementation tools
> > > =95 Design entry, synthesis and verification capabilities
> > > =95 Data2MEM =96 application for loading on-chip memory
>
> > > It looks like it's included standard.
>
> > Yes, I see that execute file data2mem, look like old day command
> > line. =A0Guessing it's just another non-user-friendly Xilnx apps ;-)
>
> > Thanks
>
> Console apps are user-friendly matter of who their friends are ;)
>
> Some examples should be helpfulhttp://home.mnet-online.de/al/BRAM_Bitstre=
ams.html
>
> There is also app for updating picoblaze code through jtag that also
> could be useful after some modifications.http://forums.xilinx.com/xlnx/bo=
ard/message?board.id=3DPicoBlaze&messag...
In my app, the data width is 1 bit, with 128k depth, that means I have
8 BRAM16 inst
---------below is my bmm file
ADDRESS_SPACE mem_module RAMB16 [0x00000000:0x00001FFFF]
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B76/RAMB16BWER [0:0] PLACED =3D
X2Y12;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B79/RAMB16BWER [0:0] PLACED =3D
X2Y14;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B82/RAMB16BWER [0:0] PLACED =3D
X2Y13;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B85/RAMB16BWER [0:0] PLACED =3D
X2Y15;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B88/RAMB16BWER [0:0] PLACED =3D
X2Y17;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B91/RAMB16BWER [0:0] PLACED =3D
X2Y18;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B94/RAMB16BWER [0:0] PLACED =3D
X2Y19;
END_BUS_BLOCK;
BUS_BLOCK
XLXI_2/MEM_MODULE/BRAM_MODULE_INST/B97/RAMB16BWER [0:0] PLACED =3D
X2Y16;
END_BUS_BLOCK;
END_ADDRESS_BLOCK;
----below is the command line I try to see if I can extract the data
from existing bit file
$ data2mem -bm mybmmfile.bmm -bt existingbitfile.bit > log.txt
-------- But it always gives the below error
ERROR:Data2MEM:29 - Inconsistent address space size in ADDRESS_SPACE
'mem_module'.
ADDRESS_SPACE was defined as 0x00020000 bytes, but the
ADDRESS_RANGE total is 0x00004000 bytes.
---Then I try to change the address space to
ADDRESS_SPACE mem_module RAMB16 [0x00000000:0x000003FFF],
---It then gives no error but the log.txt file is just a blank,
nothing show up
---I wonder if this tool can't handle data width with 1 bit wide????
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