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
Duane Clark wrote: > Yes, I am talking about one-hot encoding. Where I have seen the problem > is on power... Uggh, that should say power-on. -- My real email is akamail.com@dclark (or something like that).Article: 71151
Hi, Thanx for your reply > The ISE schematic viewer didn't show you everything. If you implement > the design and look at the ncd file with the FPGA editor, you will see > that outD and outD1 come from two different places. As far as I can see FPGA editor is not part of the WebPack tools so I can't use that. I've tried following lines with the floorplanner, but automatic place and route leave all SRL16 unplaced and unrouted (that is an other mistery not yet clear to me why that happens or rather doesn't happen). Is this a bug in the ISE schematic viewer that it doesn't show the correct schematic? I've tried switching off the SRL16 generation and then I get the correct schematic (although with 256 seperate FF ofcourse) > > Changing outD1 <= fifo(28); to outD1 <= fifo(7); (or any other number > > below 16) generates two shift registers as expected. Did I run into a > > SRL16's are used for the shift registers. Two outputs cannot come from > the same SRL16 as it uses one LUT. For bit 0 and 28 case, they can be > taken from different SRL16's, so only one 256-bit shift register is > needed (16 SRL16). For bit 0 and 7 (or anything < 16) case, two shift > registers have to be used (one 249 bit and the other one 7 bit). I understand that part. I will try to get both (28) and (27) to see what the tool tries to do in that case. Because that should split the shift register too. > > HTH, > Jim (jimwu88NOOOSPAM@yahoo.com remve NOOOSPAM) > http://www.geocities.com/jimwu88/chips > > > > XST bug or do I something terribly wrong (I'm new to VHDL). > > Version used 6.1.03i (It isn't the latest version I think but happens > > to be on the PC I'm using at the moment) > > > > Thanx, > > Peter > > > > > > library IEEE; > > use IEEE.STD_LOGIC_1164.ALL; > > use IEEE.STD_LOGIC_ARITH.ALL; > > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > > > -- Uncomment the following lines to use the declarations that are > > -- provided for instantiating Xilinx primitive components. > > -- library UNISIM; > > -- use UNISIM.VComponents.all; > > > > entity test2 is > > port ( > > clk: in std_logic; > > inD: in std_logic; > > outD1: out std_logic; > > outD: out std_logic > > ); > > end test2; > > > > architecture Behavioral of test2 is > > signal fifo: std_logic_vector(0 to 255); > > > > begin > > process(clk, inD) > > begin > > if (clk'event and clk='0') then > > fifo <= fifo(1 to 255) & inD; > > end if; > > end process; > > outD1 <= fifo(28); > > outD <= fifo(0); > > > > end Behavioral;Article: 71152
I've been reading papers about routing in island-style FPGAs. Most cite Xilinx architectures, though I've looked at a few papers about H-tree networks. Often, there is a simplified model being used. There is mention (kind of dated) that commercial routers use derivatives of maze routing, with some more recent mention of channel routing. Is there some papers that can give a good idea of how the real industry software does global and detailed routing, what algorithms are actually used? What is the typical lag time between the advent of certain approaches in conference/journal papers versus uptake in commercial routers? I'm kind of curious how much I can should trust the papers as an indication of actual practice. As well, I am still in rummaging mode, and have yet to rummage into a paper that shows how the switches in the switch boxes are actually explored to get detailed routing, given a non-full crossbar. I've looked at Wu &Tsukiyama et al.: Graph analysis of 2D FPGA routing but I'm hoping to rummage into something more applied. Thanks. Fred -- Fred Ma Dept. of Electronics, Carleton University Ottawa, Ontario, CanadaArticle: 71153
Hi is the Xilinx FPGA bitstream AutoCRC documented somewhere? XAPP151 only covers normal CRC what is not used for Virtex2/Pro and S3 FPGAs. I guess the CRC itself is calculated with same CRC code, but there must be something different as all my attempts to calc the the proper AutoCRC have been failing so far. any help appreciated :) AnttiArticle: 71154
guhaoqi <guhaoqi@liv.ac.uk> writes: > Does somebody has some paper or document about the speed between FPGA > and computer. Please send to me uliverpool@163.com thank you! How long is a piece of string?Article: 71155
Does anyone know if Xilinx released the source files for the demo stuff that comes on the $99 Spartan 3 board you can order from them (made by digilent). I have the board, and would like to experiment with the vga that is demonstrated in the test demo, but I cannot find any reference to any source files. Thanks, HankArticle: 71156
On Sat, 10 Jul 2004 00:36:10 GMT, "Hank" <nospam@nospam.com> wrote: >Does anyone know if Xilinx released the source files for the demo stuff that >comes on the $99 Spartan 3 board you can order from them (made by digilent). I >have the board, and would like to experiment with the vga that is demonstrated >in the test demo, but I cannot find any reference to any source files. > >Thanks, > >Hank > There are zip files for two reference designs at the bottome of this page: http://www.xilinx.com/products/spartan3/s3boards.htm The MicroBlaze Master System file contains code for, among other things, a vga controller. I don't know if it's the same controller that's programmed into the board's config PROM. Seems pretty strange that the source files weren't on the CDs that came with the board. Bob Perlman Cambrian Design WorksArticle: 71157
<snip> > There are zip files for two reference designs at the bottome of this > page: > > http://www.xilinx.com/products/spartan3/s3boards.htm > > The MicroBlaze Master System file contains code for, among other > things, a vga controller. I don't know if it's the same controller > that's programmed into the board's config PROM. > > Seems pretty strange that the source files weren't on the CDs that > came with the board. > > Bob Perlman > Cambrian Design Works > Hey Bob, Thanks, I will look at those files...I saw them earlier, but thought/think they are not what is on this starter kit board. There is no mention of this board using the microblaze core. Good! I thought it was strange that source files were not on the CDs...at least I feel vindicated for my feelings of frustration. :-/ I have poured over the included Starter kit resource CD, but all it contains is a bunch of pdf app notes, copies of the included manuals, and a bunch of jpg images of the spartan 3 icon playing with himself. hankArticle: 71158
"Hank" <nospam@nospam.com> wrote in message news:_XHHc.43876$qw1.43300@nwrddc01.gnilink.net... > <snip> > > There are zip files for two reference designs at the bottome of this > > page: > > > > http://www.xilinx.com/products/spartan3/s3boards.htm > > > > The MicroBlaze Master System file contains code for, among other > > things, a vga controller. I don't know if it's the same controller > > that's programmed into the board's config PROM. > > > > Seems pretty strange that the source files weren't on the CDs that > > came with the board. > > > > Bob Perlman > > Cambrian Design Works > > > > Hey Bob, > > Thanks, I will look at those files...I saw them earlier, but thought/think they > are not what is on this starter kit board. There is no mention of this board > using the microblaze core. > > Actually, I think the zip files you mentioned might indeed be what I was looking for. Thanks Bob! HankArticle: 71159
>Right, I should say that this design with 20MHz and 1 out of 10 failure >rate is just one of several designs that I have problems with. I don't >only want to solve the problem for that particular one design; I want to >learn as much as possible about this issue, so that I can solve the >problem for all my designs and avoid it in the future. Everything I've seen so far points to troubles with the initial state and the first transition - the time when reset during configuration goes away. The basic problem you have to understand is that the global reset signal is asynchronous. The next problem is that much of the software doesn't beat you over the head with that fact. (Every FF in the chip has this problem. Mostly we just ignore it and get away with it.) FPGAs work well with one-hot state machines. But if you use that encoding, then it takes a lot of logic to detect an invalid state. If you want to detect invalid states, it's probably less total logic to use a denser encoding. It's free if you use a ROM. At slow speeds with 16 or fewer states, a binary encoding may be fine. So the other approach is to avoid getting into invalid states. The first key step is to make sure that all your normal logic inputs meet setup/hold times. Metastability comes in here. My rule of thumb is to use 2 FFs (costs a whole cycle) so I don't have to think about it. Well, you actually do have to think about it - they must be near eachother. If the placer puts them on opposite sides of the chip the routing delay can cause problems. You should be able to avoid that with timing constraints. If you don't want to wait that extra clock cycle then you have to think carefully. At 20 MHz with a modern chip it should be easy. Check the app notes and such. Now all that's left is that pesky initial reset. If your state machine starts in state IDLE and stays there until some external event comes along then you are probably safe with no extra logic. You just have to make sure that no "event" happens until several clocks after initialization. Many times that happens for free. If your events do happen early, you can add a simple state machine to mask them for a few cycles. You get that right by inspection - that is you design it as logic rather than a FSM. Some state machines start off running, for example to generate a pattern of constantly running timing pulses. You can make them safe by modifying them to wait for an artifical event. If you feed in an event of "1", things reduce to the previous paragraph. For a simple one-hot encoding that starts off running, you can detect the illegal states that result when things go wrong without a lot of logic. That is don't catch all illegal states, just the ones that can happen due to asynchronous reset troubles. This has been an interesting discussion. Seems like good bait for an app-note. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 71160
Xilinx Virtex II Pro part using version 6.2.02 of the Xilinx Place and Route tools. The source of the design is an edif file produced by Leonardo. A complete Place and Route on the device takes approximately 3 hours (2.5G CPU, 2G physical RAM, Win2000) During an integration (de-bugging) stage for a project I have the need to quickly change the contents of a Goregen generated memory look-up-table. While generating the Gcoregen part I can use a .coe file to define the contents and this becomes embedded into the resultant Coregen generated .edn file. However I'm sure that repeatedly re-generating an .edn file with new values is not the most efficient way to go. At what stage during the place and route process are the values in .edn files for Coregen parts used? More importantly, is there a (relatively) easy and quick way of changing the values programmed into memory at the back end stage of place and route, but before the programming file generation stage? A search of the Xilinx web site always seems to bring up the use of the .coe (initialisation) file used at the time of Coregen generation but this surely cannot the way of programming different initial values into memories when a Goregen memory part is used multiple times within a design? -- Alan mailto:news2me_a_2003@amacleod.clara.co.ukArticle: 71161
Hi Fred, These days, the best academic routers do combined global + detailed routing using negototiated congestion. The base algorithm employed is known as Pathfinder -- see "Placement and Routing Tools for the Triptych FPGA" by C. Ebeling, L. McMurchie, S.A. Hauck, and S. Burns. A widely used tool is VPR (by Vaughn Betz), which performs clustering, followed by placement (via simulated annealing), and then timing-driven negotiated-congestion based routing. It uses an improved form of the Pathfinder algorithm, but what exact improvements it adds I forget, since VPR was commercialized and I no longer remember what was in the original academic version! I *think* that VPR (or some improved version of it) is still the best academic router, quickly providing small channel widths and good timing. There is a book "Architecture and CAD for Deep-Submicron FPGAs" by Betz, Rose, and Marquardt that covers the algortihms employed in VPR and T-VPACK (a timing-driven clusterer by Marquardt). It also covers the architecture of island-style FPGAs and various experiments on the detailed routing design. And there are a slew of papers at FPGA, ICCAD, FPL and other conferences on FPGA routing. Go to http://www.eecg.toronto.edu/~vaughn/ to see information on the "purple book" plus a list of papers on VPR by Vaughn -- the refernces in these papers should serve as good starting point. Regards, Paul Leventis Altera Corp.Article: 71162
Hello, Although i have gone through the Discussion on this forum regarding the DLL usage, i would like to clarify a point. I.e, I am having a single clock. I don't have phase shifting, clock division, clock multiplication requirements. And ofcoures i don't bother about the clock jitter. Now do i require DCM? If so why ? Thanks in advance Regards, MuthuArticle: 71163
Jason Zheng <jzheng@jpl.nasa.gov> wrote in message news:<ccmk9i$jdg$1@nntp1.jpl.nasa.gov>... > How does the icarus compiler compare with the commercial ones, e.g. > modelsim, ncverilog, etc.? For the price, Icarus has far the best benefit/cost relationship you can find in the industry (that ratio actually equals \inf ;^) Seriously, it has a very complete set of features and Steve is continuously adding fixes and improvements, specially now towards 1364-2001 compatibility. It is a very good tool if you need to write Verilog simulations and testbenches. We generally use it to design and verify our models before synthesis (it is very lightweight so you can carry it around). It dumps VCD files that you can import in most simulation tools. IIRC, there are some online comparisons of its features you can find googling. Cheers. -- PabloBleyerKocik / pbleyer2004 /"Simplicity is prerequisite for reliability." @embedded.cl / -- Edsger Wybe DijkstraArticle: 71164
"Mike Collier" <petrapam1943@yahoo.com> wrote in message news:40ed6d74$0$11773$5402220f@news.sunrise.ch... > We have been using Xilinx Student Edition 2.1i in a Third World > university for several years. Now that we have upgraded to Windows-XP, > it refuses to install, giving a message that java.exe is producing an > unhandled exception (looks like stack problem). Does anyone know of a > fix that would allow us to use the older software on the new operating > system? If so, it would save us changing devices, software and > experiment boards with our non-existent foreign currency. Any ideas? > What Eric said, request a copy of ise for the lab, and use the webpack for students.Thats what we do for a subject I tutor. May be able to request an old version of ise ? Tried changing the java version to a newer one ? Don't know if this would work but may be worth a shot. Can you install win98 under vmware or other similar software ? Or try to use an older version of webpack that supports the devices you need but installs. The nice thing about 2.1 was the simple builtin simulator. AlexArticle: 71165
Hi, Has anybody tried running Nios2 Evaluation Version on a Parallax SmartPack (Cyclone) board? Thanks, HimaniArticle: 71166
thanx for the info, was looking for the same information ... thx "Paul Leventis (at home)" <paul.leventis@utoronto.ca> wrote in message news:uWQHc.850486$Ar.77113@twister01.bloor.is.net.cable.rogers.com... > Hi Fred, > > These days, the best academic routers do combined global + detailed routing > using negototiated congestion. The base algorithm employed is known as > Pathfinder -- see "Placement and Routing Tools for the Triptych FPGA" by C. > Ebeling, L. McMurchie, S.A. Hauck, and S. Burns. A widely used tool is VPR > (by Vaughn Betz), which performs clustering, followed by placement (via > simulated annealing), and then timing-driven negotiated-congestion based > routing. It uses an improved form of the Pathfinder algorithm, but what > exact improvements it adds I forget, since VPR was commercialized and I no > longer remember what was in the original academic version! I *think* that > VPR (or some improved version of it) is still the best academic router, > quickly providing small channel widths and good timing. > > There is a book "Architecture and CAD for Deep-Submicron FPGAs" by Betz, > Rose, and Marquardt that covers the algortihms employed in VPR and T-VPACK > (a timing-driven clusterer by Marquardt). It also covers the architecture > of island-style FPGAs and various experiments on the detailed routing > design. And there are a slew of papers at FPGA, ICCAD, FPL and other > conferences on FPGA routing. Go to http://www.eecg.toronto.edu/~vaughn/ to > see information on the "purple book" plus a list of papers on VPR by > Vaughn -- the refernces in these papers should serve as good starting point. > > Regards, > > Paul Leventis > Altera Corp. > >Article: 71167
The MicroBlaze zip file on the web site includes an OPB VGA character mapped core with software drivers to use the core. The MicroBlaze Master system also includes a FSL PS/2 keyboard core with drivers. The web site with the reference designs is: http://www.xilinx.com/products/spartan3/s3boards.htm Shalin- Hank wrote: > "Hank" <nospam@nospam.com> wrote in message > news:_XHHc.43876$qw1.43300@nwrddc01.gnilink.net... > >><snip> >> >>>There are zip files for two reference designs at the bottome of this >>>page: >>> >>>http://www.xilinx.com/products/spartan3/s3boards.htm >>> >>>The MicroBlaze Master System file contains code for, among other >>>things, a vga controller. I don't know if it's the same controller >>>that's programmed into the board's config PROM. >>> >>>Seems pretty strange that the source files weren't on the CDs that >>>came with the board. >>> >>>Bob Perlman >>>Cambrian Design Works >>> >> >>Hey Bob, >> >>Thanks, I will look at those files...I saw them earlier, but thought/think > > they > >>are not what is on this starter kit board. There is no mention of this board >>using the microblaze core. >> >> > > > Actually, I think the zip files you mentioned might indeed be what I was looking > for. Thanks Bob! > > Hank > >Article: 71168
Hi I'm trying to understand the PCI specifications, and there are some timings specs I don't understand. They say that : * For output: t_val is CLK to output valid : min 2ns max 11ns * For input: t_su is Setup time beforce CLK : min 7ns t_h is Hold time after CLK : min 0ns * At 33Mhz, clk period is 30ns What is an input for one chip of the bus is an output for another one. So : Why does t_val need to be min 2ns ? For the one that samples the signal, t_h must be 0ns. Why max 11ns ? Since setup time is min 7ns ... Also, I suppose that the output signal that must be set within 2ns->11ns will only be sampled by the receiver side at the next clock cycle. Sylvain MunautArticle: 71169
Muthu wrote: > Hello, > > Although i have gone through the Discussion on this forum regarding > the DLL usage, i would like to clarify a point. > > I.e, I am having a single clock. I don't have phase shifting, clock > division, clock multiplication requirements. And ofcoures i don't > bother about the clock jitter. > > Now do i require DCM? If so why ? > > Thanks in advance > > Regards, > Muthu That depends of the clock frequency and timing requirement to meet. I'd say no, else, you'd know you want it ;)Article: 71170
Colin wrote: > And if there isn't a 32-bit CRC trailer, how can > we calculate and add this? You can do it in SW (using NIOS) or FPGA. Latter one is of course much faster but takes some resources. Try googling for "crc32 calculation". I've used this source for SW implementation: http://cell-relay.indiana.edu/cell-relay/publications/software/CRC/32bitCRC.c.html And if you want to do it in HW, try this tool that generates synthesizable VHDL/Verilog: http://www.easics.com/webtools/crctool -JS-Article: 71171
>I.e, I am having a single clock. I don't have phase shifting, clock >division, clock multiplication requirements. And ofcoures i don't >bother about the clock jitter. The DLL is normally used to reduce the clock-out delay. Is that interesting to you? -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 71172
"Paul Leventis (at home)" wrote: > > These days, the best academic routers do combined global + detailed routing > using negototiated congestion. The base algorithm employed is known as > Pathfinder -- see "Placement and Routing Tools for the Triptych FPGA" by C. > Ebeling, L. McMurchie, S.A. Hauck, and S. Burns. A widely used tool is VPR > (by Vaughn Betz), which performs clustering, followed by placement (via > simulated annealing), and then timing-driven negotiated-congestion based > routing. It uses an improved form of the Pathfinder algorithm, but what > exact improvements it adds I forget, since VPR was commercialized and I no > longer remember what was in the original academic version! I *think* that > VPR (or some improved version of it) is still the best academic router, > quickly providing small channel widths and good timing. > > There is a book "Architecture and CAD for Deep-Submicron FPGAs" by Betz, > Rose, and Marquardt that covers the algortihms employed in VPR and T-VPACK > (a timing-driven clusterer by Marquardt). It also covers the architecture > of island-style FPGAs and various experiments on the detailed routing > design. And there are a slew of papers at FPGA, ICCAD, FPL and other > conferences on FPGA routing. Go to http://www.eecg.toronto.edu/~vaughn/ to > see information on the "purple book" plus a list of papers on VPR by > Vaughn -- the refernces in these papers should serve as good starting point. Thanks, Paul, I did in fact encounter Vaughn Betz's papers on VPR. There is pretty intuitive description of the VPR, and Pathfinder is described as an iterative application of shortest path. I'm still gnawing breadth-first on promising references from web-found papers. I'll look more closely at Pathfinder to see if it details how the switchbox settings are determined. Thanks for the pointer to Vaughn's book. If anyone can comment on how relatively wide-spring are the various algorithms, both in academia and industry, that would be helpful. Papers often reference other papers, but don't actually indicate which algorithms are used by which commercial tools, and how prevalent are the various commercial tools. Vaughn's website says Right Track is now part of Altera, so maybe Altera's own tools may start using ideas from VPR. I have yet to come across information about what was the algorithm prior to this. What about Xilinx? Is it the case that they don't like to disclose the actual inner workings of their native tools? How common is it to use 3rd party tools for place-and-route rather than those from the vendor? In general, information about which commercial tool (vendors) use which algorithms seems much rarer than just the algorithms presented in isolation. Fred -- Fred Ma Dept. of Electronics, Carleton University Ottawa, Ontario, CanadaArticle: 71173
if reset equals to 1 out0 all bits equal to 0Article: 71174
"Muthu" <muthusnv@yahoo.co.in> wrote in message news:4f8e807b.0407100405.1f0b8dde@posting.google.com... > Hello, > > Although i have gone through the Discussion on this forum regarding > the DLL usage, i would like to clarify a point. > > I.e, I am having a single clock. I don't have phase shifting, clock > division, clock multiplication requirements. And ofcoures i don't > bother about the clock jitter. > > Now do i require DCM? If so why ? > > Thanks in advance > > Regards, > Muthu For data into the FPGA: The FPGA IOB's input setup/hold time requirement is defined with respect to the clock at the IOB registers. If your input clock (to the FPGA) is connected to an IBUFG (a clock-capable IOB), then to a DLL or DCM, then to a BUFG (with the output of the BUFG connected to the DLL/DCM's feedback port), then the edges of your input clock will be coincident with the clock edges on the FPGA's internal clock net (i.e., the output of the BUFG). This is known as "de-skewing" an input clock. This clock net can be used to clock the IOB registers -- and when you do this, the timing relationship, at the IOB's register input, is known with respect to your external clock. This is critical when your data rate is fairly high. You'll have to do a timing analysis to see if de-skewing your input clock is required. If you don't de-skew, then you'll have a more unpredictable relationship between your input clock and the internal clock net (that is clocking your input data). For data out of the FPGA: You can route the BUFG-to-DLL/DCM feedback path outside of the FPGA (using an external trace). This will have the effect of making your output data edges coincident with those of your input clock. Hope this helps. Bob
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