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
Daniel Köthe <d.koethespam@colour-control.com> wrote in message news:<c8f1te$9ir$1@news.eastlink.de>...
> Hello,
> i think in the last release of Xilinx Webpack 6.1 or 6.2 the abilitiy
> has added to initialize a blockram from file by xst. But this feature is
> not documented by xilinx or 1 don't found it.
>
> Has anyone used this feature?
You can certainly do it using Core Gen. Also, if you look under
language templates in Project Navigator, you can do it with defparams:
// RAMB16_S1: Virtex-II/II-Pro, Spartan-3 16kx1 Single-Port RAM
// Xilinx HDL Language Template version 6.1i
RAMB16_S1 RAMB16_S1_inst (
.DO(DO), // 1-bit Data Output
.ADDR(ADDR), // 14-bit Address Input
.CLK(CLK), // Clock
.DI(DI), // 1-bit Data Input
.EN(EN), // RAM Enable Input
.SSR(SSR), // Synchronous Set/Reset Input
.WE(WE) // Write Enable Input
);
// The following defparam declarations are only necessary if you
wish to change the default behavior
// of the RAM. If the instance name is changed, these defparams
need to be updated accordingly.
defparam RAMB16_S1_inst.INIT = 1'h0; // Value of output RAM
registers at startup
defparam RAMB16_S1_inst.SRVAL = 1'h0; // Ouput value upon SSR
assertion
defparam RAMB16_S1_inst.WRITE_MODE = "WRITE_FIRST"; // WRITE_FIRST,
READ_FIRST or NO_CHANGE
// The following defparam INIT_xx declarations are only necessary
if you wish to change the initial
// contents of the RAM to anything other than all zero's.
defparam RAMB16_S1_inst.INIT_00 =
256'h0000000000000000000000000000000000000000000000000000000000000000;
Cheers,
JonB
Article: 69751In article <e87b9ce8.0405190623.168bb823@posting.google.com>, Jon Beniston <jon@beniston.com> wrote: >> The weird register window mechanism from NIOS (is it called NIOS1 now?) >> didn't work well in embedded processing markets. > >Well, you can hardly call it weird (at least one mainstream arch, >SPARC, uses it), and in the embedded space, Tensilica have no problems >selling their arch, which also features register windows. Just because it is used, doesn't mean its a good idea. Register windows suck. Register windows reinvented (rotating register file from the IA64 suck as well). If you want fast function-call save/restore, observe that going into a cache or memory, you often have a wide interface, so the cost of writing 4 ALIGNED words is the same as writing one, and have aligned 4 or aligned 8 load/store instructions. Remember the FPGA mantra: Wires are cheap, switching the wires is expensive. >If you really want to sling some mud, my favourite part is where they >talk about "Avoiding processor obsolescence"... Er, hasn't this has >just made NIOS obsolete? How long before they change their minds >again? Nah, because NIOS1 will still be around. One of the great things about soft-cores is they are a bit easier to keep "in production" compared with a hard core. >Fair play to them, I didn't really think too much of NIOS, but if they >really can push 200MHz with this, then I am impressed. Looking at the talk at FPGA on some of the arch tricks used to make the ALU so short in NIOS-1, it might be possible. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 69752
Sean,
Brute force!
As long as the locked signal is low, periodically reset the DCM, and see
if the locked signal remains low.
It takes a little state machine, and it would have to run off the DCM
CLKIN (which is OK, just assume it is running at 25 MHz to calculate how
many counts you need to wait to make sure that LOCKED has gone high).
Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM,
use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset
the DCM).
(pseudo code below)
while CLKIN_STOPPED = 1 (clock is running)
assert (reset for one clock)
wait XX uSec
check DCM: DCM not operating? (check approp. status)
assert reset (for one clock)
wait XX uSec
else do nothing
wait XX uSec (use one counter for all waits)
go to check DCM
Austin
Sean Durkin wrote:
> Hi *,
>
> I use several DCMs in my V2P7-design, and have the following problem:
>
> After the FPGA is configured, the input clock is outside of DCM specs
> (it's somewhere in the 1MHz-range). Of course, the DCMs can't achieve a
> lock with this. Awhile later (the exact time is unknown) the input clock
> is switched to 25MHz. In order for the DCMs to lock, I then have to
> issue an external reset.
>
> What I'd like is some way to do this automatically. Normally, I'd use
> the status(1)-bit from the DCM, which should indicate the input clock
> was lost while changing. But this bit is obviously only set when a lock
> was achieved before and the clock is lost after that. If the DCM never
> locks in the first place, the status-bit is never set.
>
> The main problem here is that I don't know exactly when the input clock
> will be changing, i.e. when I have to issue the reset.
>
> Any ideas? Is there some clever way to do this I'm not seeing?
>
> cu,
> Sean
Article: 69753Yes, I have been there. If I did not overlook something, there are error reports with the same number and keyword, however, from the impact programmer. I have the error with 'translate' process. Thanks anyway :-) Klaus, Have you been to the Xilinx website answer search thingy? I put ERROR:Portability:90 into the search and had four answers appear. Somewhere to start. Cheers, Syms.Article: 69754
All, If you can compile your code from c, who cares what the architecture is? Sorry, but it really doesn't matter. Speed, and ease of use are what counts in this business. Apologies to processor architects, but unless you are doing a research project, hardly anyone cares anymore about these details. At lunch the other day we were reminiscing about how the Z8000 never took off because they changed their architecture and instruction set completely from the Z80 and immediately alienated all of their customers (who were still programming in assembly language in those days). Not like that anymore. Austin PS: check out http://biz.yahoo.com/prnews/040518/sftu114_1.html Nicholas C. Weaver wrote: > In article <e87b9ce8.0405190623.168bb823@posting.google.com>, > Jon Beniston <jon@beniston.com> wrote: > >>>The weird register window mechanism from NIOS (is it called NIOS1 now?) >>>didn't work well in embedded processing markets. >> >>Well, you can hardly call it weird (at least one mainstream arch, >>SPARC, uses it), and in the embedded space, Tensilica have no problems >>selling their arch, which also features register windows. > > > Just because it is used, doesn't mean its a good idea. Register > windows suck. Register windows reinvented (rotating register file > from the IA64 suck as well). > > If you want fast function-call save/restore, observe that going into a > cache or memory, you often have a wide interface, so the cost of > writing 4 ALIGNED words is the same as writing one, and have aligned 4 > or aligned 8 load/store instructions. Remember the FPGA mantra: Wires > are cheap, switching the wires is expensive. > > >>If you really want to sling some mud, my favourite part is where they >>talk about "Avoiding processor obsolescence"... Er, hasn't this has >>just made NIOS obsolete? How long before they change their minds >>again? > > > Nah, because NIOS1 will still be around. One of the great things > about soft-cores is they are a bit easier to keep "in production" > compared with a hard core. > > >>Fair play to them, I didn't really think too much of NIOS, but if they >>really can push 200MHz with this, then I am impressed. > > > Looking at the talk at FPGA on some of the arch tricks used to make > the ALU so short in NIOS-1, it might be possible. > > >Article: 69755
Hi Austin, Austin Lesea wrote: > Sean, > > Brute force! > > As long as the locked signal is low, periodically reset the DCM, and see > if the locked signal remains low. > > It takes a little state machine, and it would have to run off the DCM > CLKIN (which is OK, just assume it is running at 25 MHz to calculate how > many counts you need to wait to make sure that LOCKED has gone high). > > Also use the CLKIN_STOPPED bit, and if you use the DFS part of the DCM, > use the CLKFX_STOPPED status bit as well (if anything goes wrong, reset > the DCM). OK, that's exactly what I did... I just thought maybe there is some more "elegant" way to do this I'm not seeing. But if the pros say that is the way to go I'll stick with it. :) Thanks for the confirmation, Austin! cu, SeanArticle: 69756
In article <c8fsde$a5q1@cliff.xsj.xilinx.com>, Austin Lesea <austin@xilinx.com> wrote: >All, > >If you can compile your code from c, who cares what the architecture is? > >Sorry, but it really doesn't matter. > >Speed, and ease of use are what counts in this business. > >Apologies to processor architects, but unless you are doing a research >project, hardly anyone cares anymore about these details. I disagree on the register window front. It is a pain if you are doing garbage collectors (you have to flush the windows), but more importantly, it DOES impact performance. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 69757
Ok Klaus, The first hit was Answer Record # 9936 :- >>>>> Problem Description: Keywords: NgdBuild, error, portability, 90, command, line Urgency: Standard General Description: When running NGDBuild, the following error occurs: ERROR:Portability:90 - Command line error: Argument "C:\temp\design.edn" has an invalid extension. The valid extension is ".ngd". If your file name has more than one "." in it you must explicitly enter the full file name with its extension. Solution 1: This error is usually the result of having a space in the path leading to the macro search directory. For example, if the macro search path was set to: C:\Program Files\libraries NGDBuild would issue the above error. Xilinx tools do not support any white space in directory or file names. To work around the problem, do not reference any files with spaces in the path. <<<<< You read this, right? Just that I see no mention of Impact. So, any white space in the pathname of your file? Cheers, Syms. <khiltrop@gesytec.de> wrote in message news:c8fs6a$l8h$1@swifty.westend.com... > Yes, I have been there. If I did not overlook something, there are error > reports with the same number and keyword, however, from the impact > programmer. > > I have the error with 'translate' process. > > Thanks anyway :-) > > Klaus, > Have you been to the Xilinx website answer search thingy? I put > ERROR:Portability:90 into the search and had four answers appear. > Somewhere to start. > Cheers, Syms.Article: 69758
"John_H" <johnhandwork@mail.com> wrote in message news:<K3wqc.13$zR5.205@news-west.eli.net>... > The Coregen tool - in my humble opinion - is generally a dummies guide to > the Xilinx Library primitives. I find that instantiating my own memories, > DCMs and the such are much better done by reading up on the primitives and > doing a manual instantiation. > > You shouldn't need Coregen - which currently only produces Xilinx-specific > modules if I recall correctly - to do a proof of concept for the design. > COREgen actually contains some very useful items that are far from primitives. I use the FIFO's all the time and they work. It is a great way to implement simpler functions, too. When I work in Schematic entry I find it saves time over generating simple bus functions by placing a lot of individual primitives. Using HDL's this is less useful, but even then it can be more convenient for things like memories of odd bit widths that require multiple RAM components or ROM functions when you want to initialise them from a .coe file. There are other high level functions like distributed arithmetic FIR filters that come with the ISE tools, and of course theres all the IP listed on the Xilinx website under "IP Center" listed as "LogiCORE" or "AllianceCORE" which require COREgen to customise. Of course you can make all these functions without COREgen if you like to roll your own, but in many cases it saves time and effort to use COREgen.Article: 69759
gsm1900user@yahoo.com (GSM User) wrote: > There is a bug in ISE 6.x. You should manually LOC the IBUFG, BUFGs, > and DLL. LOC the BUFGP on the same side as input clock and LOC DLL, FB > BUFG and CLK90 BUFG on the opposite side. Good luck. > Ray Andraka, P.E. wrote: > You may have to put LOC constraints on the BUFGs and CLKDLLs. The automatic placer doesn't do so hot a job figuring out which BUFGs should be next to which CLKDLLs. The usual result is that error message. > Marc Guardiani <marc@guardiani.com> wrote: > > Run the input clock to to clock pins. On one, use the CLKDLL. On the > > other, use the IBUFG. (You didn't say you needed that other clock pin > > for something else :-). > > > > Tony Dean wrote: > > > > > I want my master input clock, which is on a dedicated pin, to clock > > > most of my logic through a BUFG. I also want it to drive a CLKDLL so I > > > can use the CLK90 output. > > > > > > After much head-banging I assert the following: > > > On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL > > > input AND a BUFG input simultaneously. > > > > > > Synplicity will synthesize this setup beautifully, but the Xilinx > > > Placer won't accept it. > > > > > > > > > A double mocha to he or she who can disprove my assertion. > > > > > > -td Problem solved! While Marc Guardiani deserves Honorable Mention for his workaround, "GSM User" and Ray Andraka have the correct answer and are entitled to the double mocha. I had discovered the same fix shortly before and am pleased to have my findings confirmed. The clue was in the hitherto-ignored error message: ERROR:Place:107 - Xilinx requires using locate constraints to preplace such connected GCLK/GCLKIO/DLL components. What this actually means apparently, is that Xilinx requires using locate constraints to preplace such connected GCLK/GCLKIO/DLL components. Details for this can be found in the bowels of the Xilinx documentation at: http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0128_81.html#wp240140 I'll forward this little tip on to the Xilinx FAE whom I opened a WebCase with, who apparently is not aware of this detail. Mochas are payable in person at any cafe here in Santa Cruz. In the event that transportation costs to and from Santa Cruz exceed the cost of a double mocha ($3), please supply PayPal address to which said amount can be promptly remitted. Thanks to all, -tdArticle: 69760
Goran Bilski <goran@xilinx.com> wrote in message news:<c8f3f0$cfe1@cliff.xsj.xilinx.com>... > It seems that Altera has created a MicroBlaze as well. > They have finally realized that a FPGA based soft processor should have > - 32 bit ISA > - 32 registers > - 3 operand instruction format > - JTAG based HW debugging > - HW divider > > The weird register window mechanism from NIOS (is it called NIOS1 now?) > didn't work well in embedded processing markets. > > Göran Bilski Ouch! I don't want to get into any marketing debates or flame wars, but I feel that inaccurate descriptions of the product I'm familiar with should be called out: - Nios I had a 16-bit ISA. You are correct sir. - Nios I had 32 registers per window (that is, per context), and a compiler option to make it a flat 32 registers (that has been in the kit for a couple years now). You are again correct that Nios II has a flat 32 registers. - Nios I had JTAG-based HW & SW debugging (for some time now!) - Nios I had a hardware divider custom instruction (in the kit!) that in two mouse clicks and a documented compiler switch had HW divides implemented. And lest we forget: - Avalon (off-chip memory at decent performance, anyone?) - SOPC Builder. - A happy user-experience implementing systems. Regards, Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 69761
"Subroto Datta" <sdatta@altera.com> wrote in message news:<n4zqc.524$1O4.119@newssvr15.news.prodigy.com>... > Vadim, make sure that you have the Unused Pins for your Quartus project set > to be Inputs Tristated. You can do this as follows after the project is > opened in Quartus: > > 1. Click on Assign Device > 2. Click on the Device and Pin Options Button > 3. Click on the Unused Pins Tab. > 4. This should be the first Radio button. > > Hope this helps. > > - Subroto Datta > Altera Corp. Just to elaborate on why this is: A feature of the Nios development boards is to demonstrate remote reconfiguration. This is done via an FPGA I/O which is connected to the MAX CPLD on the board. The MAX CPLD is programmed to re-configure the FPGA when the signal is driven low (in this way, the FPGA can send a signal telling the MAX chip to reconfigure itself). For reference designs that include this pin and leave it high, or tri-stated, there is no issue. However, a user design must either drive this pin high manually, tri-state the pin manually, or leave the pin un-assigned and tri-state the unused outputs (as Subroto's instructions indicate). Regards, Jesse Kempa Altera Corp. jkempa at altera dot comArticle: 69762
"Austin Lesea" wrote > At lunch the other day we were reminiscing about how the Z8000 never > took off because they changed their architecture and instruction set > completely from the Z80 and immediately alienated all of their customers > (who were still programming in assembly language in those days). Not quite getting it into production may have troubled some customers... > Not like that anymore. The Spartan-3 of its day ;-)Article: 69763
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote... > I have done some armchair thinking about how to keep and > combine blobs if they should merge in susbsequent lines. > This may be done by keeping start and stop points of the > various blobs in a RAM LUT. But maybe this isn't the > best approach? We identified the option that you described, and a second approach that involved keeping track of an ID for each blob that was in process and storing with each pixel in a line the blob ID that the pixel corresponded to. We did this as we had to be able to both fill the voids in blobs to get an accurate centroid of the entire blob, and also find an accurate mass and centroid for the voids in the blobs as well. We are basically looking for black circular blobs, that contain six white circular voids of varying mass. By decoding the locations of the voids, we identify one of 729 possible marks. This is used for localization of a robot, as an interim step to scene based localization. > I saw mention of run length encoding in a web page by > Wintress. I do not know what advantage that encoding has > over a fifo that would give you the pixel threshold on every > pixel clock. I do know that some camera manufacturers like > Basler make cameras that threshold and run length encode > their outputs presumably to cut down on cable bandwidth. Exactly. In some vision applications, very few features need to be found, and this can drastically reduce the bandwidth. > I am not sure what you mean by the term non-convex. To > a newbie that is concave but you don't use the word concave > so perhaps this has a different meaning. The term evolved from the notion that blobs are inherently convex. A non-convex blob has a concave feature somewhere on its boundary. > I have also come across 4 neighbor or 8 neighbor terminology > which I assume represent the rules for making a connection, > based on a tic-tac-toe arrangement of pixels. I would suppose > that the 8 neighbor approach would be a tad more robust but > may lead to narrowly connected blobs with only a point in > common. Whis is better? Which mode of connection you choose is entirely application dependent. Four-connected blobs are sufficient for convex objects, eight-connected are more important if the feature size to pixel size ratio is quite small. > On my web searching I have tried to refine my search to > just source code by using unique VHDL keywords like > downto and inout. However I didn't find anything with > this search: downto inout blob. Any suggestions to > better search techniques or Verilog keywords will > be appreciated. I do not suspect you will find any source code, but please don't use my skepticism as a reason not to look. > Another roboticist. Thanks so much. > Do you want to share with the group what Birger does? Actually, our involvement with robotics has been limited to the development of a vision system for a robot. Birger is primarily involved in the development of vision and compression algorithms on FPGAs. The vision system that we have devloped has the following characteristics: PC/104+ form Xilinx XC2VP20-FG676 FPGA (up to a XC2VP40 will fit) 64MB DDR SDRAM (32 bit datapath) Xilinx SystemAceCF VGA LCD interface w/HV inverter for backlight Stereo Audio CODEC Nine VGA camera inputs (one color, eight mono) MJPEG compression, and color converion for color camera Stereo disparity search on four QVGA camera pairs Features that we are currently working on: Dewarp - 8 x VGA input, 8 x QVGA output Blobfinder/FiducialFinder MJPEG decompression Everything runs at 15FPS. Many of the engines run at 30+FPS. Due to power considerations, we developed the VGA cameras from scratch, which burn approximately 200mW each, and are approximately 20mm on a side. Is this hardware/IP that other robotcs developers would find useful? This has been developed for a government agency, and we are investigating how we might productize it. Regards, Erik Widding. Birger Engineering, Inc. -------------------------------- 617.695.9233 100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.comArticle: 69764
Jim Granville wrote: > > Jim Granville wrote: > <snip> > > There are a LOT of Arm cores comming as MCU, with on chip FLASH, and > > that solves the smaller-memory end, by removing the memory BUS layout > > problems. > > > > Look at Philips LPC2xxx, STm STR7xxx, Analog Devices ADuC7xxx, TIs > > TMS470, Sony, etc for FLASH+ARM offerings, many with external memory > > interfaces. > > .. I should have included Motorola's MAC7100 ARM devices, TQFP144, > 512KF, 32KR, Automotive specs.. Wow! This is a part I have been looking for for quite sometime. I don't see any info on pricing or availability... any idea? I have sent an email to Arrow, we'll see what they say. It does not look like this part will interface directly to SDRAM... too bad, that is the only lacking feature for my app, but I can live without it. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 69765
Hi, I'm trying to use Chipscope with a Virtex-e design. Problem is that my design runs with a very fast clock (>170 MHz) which is clock enabled. Chipscope needs a measurement clock and I wondered if it supports a clock enable? It can't run at the full clock rate. I couldn't find that option, so I guess I'll need to make a special clock for it. TIA, Syms.Article: 69766
> Zigbee news from Atmel - what's key here, is a move from generic
> uC/Chip sales, into also selling the Zigbee SW stack, so users have
> minimal SW developments for their links.
Nope, no move, just another group within using the AVR for a good purpose.
The AT86RF401 is the same story.
The AT76C711 AVR has been around for some time using the same concept.
The follow on device AT76C712 is moving into the general purpose
domain, and will be sold to both Fred in the Shed and Joe Sixpack.
Nice 48 MHz AVR with USB and UARTs.
> This will be key to their AVR sales, very like CypressMicrosystems
> promote their PsOC - they include Sw support flows, so customers
> need less skills.
>
> http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=Zigbee.html
>
> http://www.atmel.com/dyn/resources/prod_documents/5056S.pdf
>
> $6.75/100K for a chipset is not super-cheap, but from a NZ standpoint,
> the Zigbee solution is probably better than Bluetooth.
Each has their own uses...
Europe fought for 30 years to determine which should prevail:
Catolicism *OR* Protestantism.
Guess what ....
> Zigbee is slower, but gives more range, and suits Alarms, Security,
> Wireless Logging and similar near-field applications.
>
> Would likely also make a great marine-instrumentation link on boats,
> for non-graphical interfaces.
>
> -jg
>
--
Best Regards,
Ulf Samuelsson ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB
Article: 69767"Anders" <ankoe@EMAIL-Protected.se> skrev i meddelandet news:97810a59e9658cd3b6f25f198eb9cd14@localhost.talkaboutelectronicequipment.com... > Two months after Xilinx acquired Triscend, it now seems they are planning > to kill the Triscend products. We recently got the End-of-life > notification for the A7 processor, and I guess the E5 is also going. > > Does anybody know of a replacement for the Triscend A7 processor? We are > using it together with a Xilinx FPGA (at least until now...) and have > implemented a FIFO in the CSL to move data at high speed from the FPGA to > external SDRAM (Up to 128 Mbits/second in packets of 8 32-bit words). This > link seems to be difficult to implement using a "standard" ARM7 > processor. > > Any suggestions and views are appreciated. > > /Anders > If you use a controller like the AT91R40008 with 256 kB internal SRAM and implement the SDRAM controller in the FPGA it is a piece of cake. CPU runs at 60 MIPS, no sweat when executing out of internal SRAM. You can make a lot of transfers per microsecond... Use the FIQ interrupt into the ARM7 to get maximum throughput. The FPGA can implement its own DMA controller. Alternatively the ARM7 can do a move multiple from internal SRAM to the DRAM at a "high" address, using a special chip select signal When the FPGA sees this chipselect active, it can ignore data coming in over the CPU bus and take it from a FIFO in the FPGA. 128 Mbit / second is 8 x 16 words so you need to do 8 x 16 bit transfers per microsecond. If you dont want to worry about SDRAM controllers, use PseudoRAM (DRAM with an SRAM interface). Maybe implement a page mode feature in the FPGA. Hopes this helps Since you seem to be based in Sweden, you can contact me directly. If you have any decent volume, we have better solutions. -- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic ABArticle: 69768
Why do you think it's wierd? I found the fast ISR entrance quite useful. I hope ISR entrance is as fast in Nios II. I heard it the windowing was thrown out because of patent issues, not on its technical merits. -- Pete > > The weird register window mechanism from NIOS (is it called NIOS1 now?) > didn't work well in embedded processing markets. > > Göran Bilski > > > Kenneth Land wrote: > > >Tomorrow is the big Nios II launch date, but info is already going up.... > > > >www.altera.com > > > >http://www.fpgajournal.com/articles/20040518_nios2.htm > > > > > >Full 32bit. 2X-4X faster than Nios I and starts at only 500 LE's. New IDE. > >New Compact Flash and other periferals.... Can't wait to get a hold of it. > > > >Ken > > > > > > > >Article: 69769
> > Possibly not the same problem, but I've seen issues recently with a > > Core Gen RAM not being synthed properly by XST. I switched over to > > Synplify and the problem disappeared.. My faith in XST is limited! > > > > I didn't think that Coregen'ed stuff *was* synthesised - does the > synth not see it as a black box? Then the downstream tools find the > EDIF netlist to fill in the gap.. Could it wire up the black box wrong? Functional sim worked okay and post-translate sim didn't (neither did h/w). It could have been the translate prog that screwed up I guess, but I didn't have the time or will to find out. Whenever things like that have happened before, switching to Synplify always fixed it. Cheers, JonBArticle: 69770
It's creating weird situation in embedding processing where you reach the limit of the window. There should only be different 3 numbers used as sizes, 0, 1 or infinity. Any other number will creating barriers that will be reach and have impacts on the system. On reaching the limit of the register window, you have a big chunk of data to save and load which isn't nice to have when you need to have a deterministic system. Göran Peter Sommerfeld wrote: >Why do you think it's wierd? I found the fast ISR entrance quite >useful. I hope ISR entrance is as fast in Nios II. I heard it the >windowing was thrown out because of patent issues, not on its >technical merits. > >-- Pete > > > >>The weird register window mechanism from NIOS (is it called NIOS1 now?) >>didn't work well in embedded processing markets. >> >>Göran Bilski >> >> >>Kenneth Land wrote: >> >> >> >>>Tomorrow is the big Nios II launch date, but info is already going up.... >>> >>>www.altera.com >>> >>>http://www.fpgajournal.com/articles/20040518_nios2.htm >>> >>> >>>Full 32bit. 2X-4X faster than Nios I and starts at only 500 LE's. New IDE. >>>New Compact Flash and other periferals.... Can't wait to get a hold of it. >>> >>>Ken >>> >>> >>> >>> >>> >>>Article: 69771
I think you're looking for a way to initialize the RAM after the FPGA is placed and routed so you don't need to recompile? If you use the .ucf file to initialize the RAM it will require re-running place-and-route. There is an article on merging RAM data directly into the bitstream file in the TechXclusives section of Xilinx.com titled "Reconfiguring Block RAMs" by Kris Chaplin jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405190626.2c08ec5@posting.google.com>... > Daniel Köthe <d.koethespam@colour-control.com> wrote in message news:<c8f1te$9ir$1@news.eastlink.de>... > > Hello, > > i think in the last release of Xilinx Webpack 6.1 or 6.2 the abilitiy > > has added to initialize a blockram from file by xst. But this feature is > > not documented by xilinx or 1 don't found it. > > > > Has anyone used this feature? > > You can certainly do it using Core Gen. Also, if you look under > language templates in Project Navigator, you can do it with defparams: > > // RAMB16_S1: Virtex-II/II-Pro, Spartan-3 16kx1 Single-Port RAM > // Xilinx HDL Language Template version 6.1i > > RAMB16_S1 RAMB16_S1_inst ( > .DO(DO), // 1-bit Data Output > .ADDR(ADDR), // 14-bit Address Input > .CLK(CLK), // Clock > .DI(DI), // 1-bit Data Input > .EN(EN), // RAM Enable Input > .SSR(SSR), // Synchronous Set/Reset Input > .WE(WE) // Write Enable Input > ); > > // The following defparam declarations are only necessary if you > wish to change the default behavior > // of the RAM. If the instance name is changed, these defparams > need to be updated accordingly. > > defparam RAMB16_S1_inst.INIT = 1'h0; // Value of output RAM > registers at startup > defparam RAMB16_S1_inst.SRVAL = 1'h0; // Ouput value upon SSR > assertion > defparam RAMB16_S1_inst.WRITE_MODE = "WRITE_FIRST"; // WRITE_FIRST, > READ_FIRST or NO_CHANGE > > // The following defparam INIT_xx declarations are only necessary > if you wish to change the initial > // contents of the RAM to anything other than all zero's. > > defparam RAMB16_S1_inst.INIT_00 = > 256'h0000000000000000000000000000000000000000000000000000000000000000; > > Cheers, > JonBArticle: 69772
"Goran Bilski" <goran@xilinx.com> wrote in message news:c8gaoj$cfb1@cliff.xsj.xilinx.com... > It's creating weird situation in embedding processing where you reach > the limit of the window. > There should only be different 3 numbers used as sizes, 0, 1 or infinity. > Any other number will creating barriers that will be reach and have > impacts on the system. > On reaching the limit of the register window, you have a big chunk of > data to save and load which isn't nice to have when you need to have a > deterministic system. > > Göran > Can you explain a bit more? If you need more than 31 levels of call stack, how deterministic could your application be? I know there is merit to what you say, as that's why NiosI has the mflat model available. I'd just like to have it explained. KenArticle: 69773
You can initialize BlockRAM after the bitfile has been created using a tools called Data2MEM that is part of the Xilinx ISE tools. To read more about Data2MEM goto: http://www.xilinx.com/ise/embedded/data2bram.htm Shalin- Gabor Szakacs wrote: > I think you're looking for a way to initialize the RAM after > the FPGA is placed and routed so you don't need to recompile? > If you use the .ucf file to initialize the RAM it will require > re-running place-and-route. > There is an article on merging RAM data directly into the bitstream > file in the TechXclusives section of Xilinx.com titled > "Reconfiguring Block RAMs" by Kris Chaplin > > jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405190626.2c08ec5@posting.google.com>... > >>Daniel Köthe <d.koethespam@colour-control.com> wrote in message news:<c8f1te$9ir$1@news.eastlink.de>... >> >>>Hello, >>>i think in the last release of Xilinx Webpack 6.1 or 6.2 the abilitiy >>>has added to initialize a blockram from file by xst. But this feature is >>>not documented by xilinx or 1 don't found it. >>> >>>Has anyone used this feature? >> >>You can certainly do it using Core Gen. Also, if you look under >>language templates in Project Navigator, you can do it with defparams: >> >> // RAMB16_S1: Virtex-II/II-Pro, Spartan-3 16kx1 Single-Port RAM >> // Xilinx HDL Language Template version 6.1i >> >> RAMB16_S1 RAMB16_S1_inst ( >> .DO(DO), // 1-bit Data Output >> .ADDR(ADDR), // 14-bit Address Input >> .CLK(CLK), // Clock >> .DI(DI), // 1-bit Data Input >> .EN(EN), // RAM Enable Input >> .SSR(SSR), // Synchronous Set/Reset Input >> .WE(WE) // Write Enable Input >> ); >> >> // The following defparam declarations are only necessary if you >>wish to change the default behavior >> // of the RAM. If the instance name is changed, these defparams >>need to be updated accordingly. >> >> defparam RAMB16_S1_inst.INIT = 1'h0; // Value of output RAM >>registers at startup >> defparam RAMB16_S1_inst.SRVAL = 1'h0; // Ouput value upon SSR >>assertion >> defparam RAMB16_S1_inst.WRITE_MODE = "WRITE_FIRST"; // WRITE_FIRST, >>READ_FIRST or NO_CHANGE >> >> // The following defparam INIT_xx declarations are only necessary >>if you wish to change the initial >> // contents of the RAM to anything other than all zero's. >> >> defparam RAMB16_S1_inst.INIT_00 = >>256'h0000000000000000000000000000000000000000000000000000000000000000; >> >>Cheers, >>JonBArticle: 69774
Eric Crabill wrote: > Hi, > > There's a tool called Universal Scan that does just what > you are looking for. http://www.universalscan.com/ > I had some students using it at SJSU to program an Intel > Flash attached to a Spartan-IIE. I was impressed with > the tool. In the last issue of Xcell-Journal (49) there is an article about it. They call it "inexpensive" ;-)
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