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 Nov 15, 10:45=A0pm, "atass" <at...@lajta.com> wrote: > No, that's completely wrong. > > =A0VCS has had Systemverilog support for at > least that long, far in advance of either Mentor Modelsim or Cadence > Incisive. =A0Synopsys's other front-end design tools (Design Compiler, > Formality, etc.) support Systemverilog quite well, and for some time, too= . > (Cadence's LEC also supports it quite well, but I couldn't try the others= .) Well, well, well. Let's read latest VCS User's Guide, "What VCS Supports": - The SystemVerilog 3.1a language (with some exceptions) as defined in SystemVerilog 3.1a Accellera=92s Extensions to Verilog Nothing about IEEE-1800-2005/2007. SystemVerilog 3.1a was predecessor, you are right. But it was five years ago (April'2004). And nothing changed! Is it an advanced support?Article: 136451
"laserbeak43" <laserbeak43@gmail.com> wrote in message news:5450554b-3756-450e-b3db-2594e477d707@a3g2000prm.googlegroups.com... > Hello, > I have a Digilent Spartan3e starter kit. One day i went out and when i > came back the lady told me that my son had dropped my kit behind my > desk. When i had a look at it, the jumpers were off of it as well. I > put them all back in their default spots according to the user guide. > the board powers up but the Done LED does not come on and i can't > perform a boundry scan without ISE hanging. My board no longer shows "done" when I power it on, but that's because I've somehow messed up the flash configuration and haven't got around to figuring out what I did. However, I can still connect to the board fine, and upload new images to the FPGA (and which point it resets and the done light comes on). My jumper configuration is (from the top, working down): J30: all closed J11: all closed JP6: closed JP9: 3.3V JP7: closed All other jumpers are open. This is the default configuration, AFAIK. If this doesn't work for you, then your board may be dead. Depending on what equipment you have available, you might be able to debug or repair it, but the FPGA being a BGA will make that a little tricky. Schematics (excluding the USB to JTAG portion) are in the user guide for the board (ug230, IIRC). [...] -- Michael Brown Add michael@ to emboss.co.nz ---+--- My inbox is always openArticle: 136452
On Nov 17, 11:06=A0am, "Michael Brown" <s...@signature.below> wrote: > "laserbeak43" <laserbea...@gmail.com> wrote in message > > news:5450554b-3756-450e-b3db-2594e477d707@a3g2000prm.googlegroups.com... > > > Hello, > > I have a Digilent Spartan3e starter kit. One day i went out and when i > > came back the lady told me that my son had dropped my kit behind my > > desk. When i had a look at it, the jumpers were off of it as well. I > > put them all back in their default spots according to the user guide. > > the board powers up but the Done LED does not come on and i can't > > perform a boundry scan without ISE hanging. > > My board no longer shows "done" when I power it on, but that's because I'= ve > somehow messed up the flash configuration and haven't got around to figur= ing > out what I did. However, I can still connect to the board fine, and uploa= d > new images to the FPGA (and which point it resets and the done light come= s > on). My jumper configuration is (from the top, working down): > J30: all closed > J11: all closed > JP6: closed > JP9: 3.3V > JP7: closed > All other jumpers are open. This is the default configuration, AFAIK. > > If this doesn't work for you, then your board may be dead. Depending on w= hat > equipment you have available, you might be able to debug or repair it, bu= t > the FPGA being a BGA will make that a little tricky. Schematics (excludin= g > the USB to JTAG portion) are in the user guide for the board (ug230, IIRC= ). > > [...] > > -- > Michael Brown > Add michael@ to emboss.co.nz ---+--- My inbox is always open We do a lot of work with BGA's here, and our standard method of finding BGA's that don't work due to unsoldered balls is to clamp the part firmly against the board and see if it works while clamped. You can try this by hand or use a tool that looks like an overgrown vise-grip with clamping pads on the end. We have such a tool and cover the pads with tape for electrical insulation. Of course the bad news is that if this works for you, it means your BGA has popped loose and unless you want to run it with the clamp on, you'll need major repairs. Cheers, GaborArticle: 136453
I'm trying to get a Xilinx Spartan-3E Starter Kit to work with a Linux computer (Fedora 9), using ISE 10.1. The problem is that Impact doesn't recognise the USB cable. First I tried installing ISE 10.1 with the "install cable drivers" box unchecked, because the installer says these drivers require RHEL (which I don't use) and root privilege (which I'm reluctant about). However, when this didn't work, I re-installed ISE 10.1 with that box checked, running in root mode. The result of this is: -- Impact still doesn't recognise the USB cable -- The Xilinx installer software took advantage of root privilege to trash my Linux system (it deleted or moved links to glibc, and now lots of other software is breaking) So, while I'm reinstalling Linux, does anyone have any suggestions on how to get the USB driver installed? Why can't Xilinx provide working software? I need a solution that doesn't involve granting root privilege to any software that comes from Xilinx. Thanks for any help! JohnArticle: 136454
Every cloud has a silver lining, but it seems every rose has its thorns too. PLLs/DCMs/DLLs (or whatever your favourite FPGA happens to offer) provide a wonderful way to create multiplied-up clocks within the device. What's more, you can line up the active clock edges so closely that you can treat the x1 and xN clock domains as if they were one single clock domain; hold times can be avoided when crossing the boundary in either direction. Until recently I've always avoided taking advantage of this, and have treated the x1 and xN clock domains as if they were asynchronous, using FIFOs or whatever to convey things across the boundary. But in a recent client engagement I was faced with a design in which a x2 and x4 clock, from the same PLL, were used in a completely sensible way as if they were in the same clock domain as the original x1 clock. The TimeQuest timing analyzer (for it was Brand A that was in use on this occasion) was quite happy to deal with these crossings, giving clear-headed and (as it turned out) accurate reports of what was going on. There is no doubt that this is cool. However, it's not so cool in RTL simulation. The PLL simulation models, not too surprisingly, introduce some delta delays between the nominally coincident clock edges. Consequently I get everything working when going in one direction (from fast clock to slow clock, as it turns out) but I get shoot-through behaviour, the RTL equivalent of a hold time violation, when crossing from slow to fast clock; data is arriving one or more delta cycles *before* the clock. We've easily enough got around this for the present design, but I'd love to know what all you seasoned PLL/DCM users out there do about it. Do you introduce small non-zero time delays in all the signals crossing the clock domains, so that it all works in simulation? Do you treat the various clock domains as if they were asynchronous, thereby losing one of the nicest benefits of the PLLs? Or do you simply accept that it's necessary to do timing simulation in order to see what will really happen? This is partly a plague of VHDL RTL sim (hence the posting to c.l.vhdl as well); in Verilog you can model clock gating and PLL-ish behaviour with "less" zero delay than the nonblocking assignments to your flip-flops, by taking care to use blocking assignment in all your clock paths. I have not yet tried the Verilog simulation models for the PLLs to see whether that makes any difference. One further whinge: I haven't tried this in Brand X recently, but the Altera PLL models are spectacularly inefficient for RTL simulation. In our modest-size project - think SDRAM controller, a few FIFOs occupying most of the blockRAM, and a fairly small bunch of additional logic - the two PLLs are responsible for at least 90% of the simulation time - OUCH. I swapped-in much simpler, but perfectly adequate in-house models and got x10 simulation speedup. Opinions/rants/insults welcomed. Thanks in advance. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 136455
On Nov 17, 3:45 am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2008-11-14, jleslie48 <j...@jonathanleslie.com> wrote: > > > need to know where to start to get RS232 comm's working, and the led's > > blinking. > > > I was kinda hoping when I opened the box to my new XUPV2P: > > >http://www.xilinx.com/products/devkits/XUPV2P.htm > > > there would be some basic, hello world programs templates to play > > with, and a demo program so that > > I could have the board send and receive messages on the DB9 > > connector. I can't seem to locate anything of the sort. Does > > anybody have a good tutorial for my first program? > > From your post I'm uncertain whether you have prior experience with > FPGAs or not. Since you are talking about a hello world program and > RS232 I suspect that you are interested in using the PPC405 processors > in the FPGA. If so, I would strongly recommend the EDK to you. > > However, if you are not interested in the EDK but still want to use the > processors it is possible to do so. I have an example design for this > at my homepage athttp://www.da.isy.liu.se/~ehliar/stuff/which worked > the last time I tried it (a year or so ago). (Search for PPC405 on the > page.) The UCF file in this design is made for the XUPV2P board. > > However, if you are not interested in using the PPC405 but still want > to use the RS232 port I would recommend the RS232-tutorial over atwww.fpga4fun.com. > > Good luck! > > /Andreas Andreas, Thanks for your links. I do have the EDK and plan to use it, I have no idea what a PPC405 processor is, :(, but I'll research it and your links before I ask for more help. I have very little experience with fpga's. I was tasked with building a device two years ago and being a C programmer, ended up using a $2000 combo board which had a xilinx chip and a TI6713 DSP on it. I had a guy that did the FPGA stuff on the xilinx chip, and I did the programming on the TI chip with code composer. Well my fpga guy is gone, and I'm now tasked with moving all my stuff over to a Xilinx Virtex II or V, C code as well as all the device controllers. Hopefully I can figure this thing out. Sincerely, JonArticle: 136456
JohnOD wrote: > I'm trying to get a Xilinx Spartan-3E Starter Kit to work with a Linux > computer (Fedora 9), using ISE 10.1. [...] > So, while I'm reinstalling Linux, does anyone have any suggestions on > how to get the USB driver installed? Why can't Xilinx provide working > software? I need a solution that doesn't involve granting root > privilege to any software that comes from Xilinx. See: http://rmdir.de/~michael/xilinx/ and http://www.xilinx.com/support/answers/29310.htm I couldn't get it working on a Debian box, but Fedora is much closer to RHEL than Debian is so there's a pretty good chance it'll take. As for the software quality problem, Xilinx appear to put more resources into new features rather than fixing existing problems (or bug testing, for that matter). An attitude that's far from unique to Xilinx, it should be said, and probably because there's a limited budget for software and "231 bugs fixed" is much harder to sell than "10 new features added". -- Michael Brown Add michael@ to emboss.co.nz ---+--- My inbox is always openArticle: 136457
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:j2fuh4dfg0ckic1h8m97lga8cggkps6rbt@4ax.com... > On Sat, 15 Nov 2008 11:45:02 -0800, "atass" wrote: > >>> While Cadence and >>>Mentor collaborated into SV support and moved forward with OVM >>>initiative, Synopsys concentrates into conventional HDL support only. >> >>No, that's completely wrong. > > Indeed it is; but your correction contains many misconceptions too. My apologies, I was in an aggressive mode when I wrote my original response. I do appreciate your patient corrections to my misconceptions! >>Synopsys acquired Superlog about 5 years ago, which was the predecessor of >>the IEEE-standard Systemverilog. > > Only of some parts of the language. Superlog was the progenitor > of many of the design-related features, and of interfaces. > Some of the OOP features of SV came out of Vera (another > Synopsys product). But none of that matters any more; SV is > a formal IEEE standard, over 3 years old now and still under > active development (expect a significant revision in 2009). > The history no longer matters very much. This is something I did not know, thanks for the correction. >> But they did it because >>both were FAR BEHIND Synopsys in terms of Systemverilog (functional >>simulation) marketshare, not because they 'were ahead of the curve.' > > Phrases like "far behind" represent value-judgements that are very > hard to back up. I'll admit that was a value judgement. I used IUS quite a bit over the past 3 years, and my personal *opinion* (not an objective measure by any means!) is that IUS's Systemverilog progress was disappointing until about a year ago (IUS61/62.) That's a sentiment echoed with a lot of engineers who've tried building their own Systemverilog testbench in these earlier IUS releases. Basically, if they didn't have a Cadence fellow on hand to guide the them around simulator and implementation obstacles, they ended up very very disappointed like I did. Some major features still aren't supported at all (unions come to mind, though I guess not too many engineers use them.) And IUS still has plenty of implementation restrictions: enum-declarations are still limited to 'literal constants', i.e. if I want to declare an address-map, I can't use an expression of 'BASE + OFFSET', the righthand-value must be a literal constant. Of the features I tried, Questasim's language support (feature-wise) "felt" more complete than Cadence. I never had access to VCS, so I don't have a full perspective on Synopsys's idiosyncracies -- I'm sure it has many. (For one thing, it won't compile OVM out of the box , so that can't be a good thing...) A lot of teams feel IUS has better runtime performance for large SoC simulations. (Since ASIC teams generally don't run identical simulation environments side by side, a claim like this is inherently hard to verify.) Having said all that, IUS81 is much much better than the earlier versions. No complaints from me now (except for the 2 nitpicks above.) >>Synopsys VMM had a de-facto standard until OVM emerged. > > Neither OVM nor VMM are in any real sense de facto standards. > They are both published, documented, supported class libraries, > and happily both are now open-source. Both are changing and > developing sufficiently fast that it would be foolish to > describe either as a standard. All three big players in this > space are working with Accellera to define interoperability > standards for verification methodology, and that can only > be a good thing for users. Looks like I drank a bit too much kool-aid from the Synopsys hype/marketing machine (and I read too much into John Cooley's user survey) :) I was under the impression, which is suspect, that early Systemverilog users overwhelmingly selected VCS, because 3+ years ago it was the only (usable) offering. (And because Synopsys was aggressive with pricing the Systemverilog early adopters.) Of those Systemverilog teams, I *assumed* a majority of them would have been directed toward VMM, which is the official best-practice/methdology for users of VCS/Systemverilog. > It is *not* a good thing for users when people spread the > kind of half-truth and unsupportable opinion-dressed-as-fact > that has been far too evident in this thread. Agreed. Indeed, when it comes to the religious EDA-tool wars, I 'll hold my tongue in the future :)Article: 136458
In comp.arch.fpga Jonathan Bromley <jonathan.bromley@mycompany.com> wrote:
...
> Opinions/rants/insults welcomed. Thanks in advance.
I have a similar problem:
20 MHz "clock_in", internal used multiplied by five, used als "clk" and
also used doubled as "clkx2"
The clock_in is not used.
I use this:
`ifdef __ICARUS__
reg clkx2 = 0;
reg clk = 0;
always @(posedge clk_in)
{clk, clkx2} <= {clk, clkx2} + {2{clk_in}};
assign alu_ctl_bits[`CMD_RST] = 1'b0;
`else
wire clk, clkx2;
clk100 dcm0
(
.CLKIN_IN(clk_in),
.RST_IN(alu_ctl_cmd[`CMD_RST]),
.CLKFX_OUT(clk80),
.CLKIN_IBUFG_OUT()
);
DCM dcmac (
.CLKIN(clk80),
.CLKFB(clkx2),
.RST(alu_ctl_cmd[`CMD_RST]),
.CLK0(clkacdcm),
.CLK2X(clkacx2dcm),
.LOCKED(alu_ctl_bits[`CMD_RST]));
BUFG clkbuf(.I(clkacdcm),.O(clk));
BUFG clkx2buf(.I(clkacx2dcm),.O(clkx2));
`endif // !`ifdef __ICARUS__
For simulation I now use clk_in == clk
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 136459Jonathan Bromley wrote: > We've easily enough got around this for the present > design, but I'd love to know what all you seasoned > PLL/DCM users out there do about it. Do you > introduce small non-zero time delays in all the > signals crossing the clock domains, so that it all > works in simulation? Do you treat the various > clock domains as if they were asynchronous, thereby > losing one of the nicest benefits of the PLLs? Or > do you simply accept that it's necessary to do timing > simulation in order to see what will really happen? Naturally, I would prefer to fix up the design to use a single clock or another "known good" synchronization scheme. If I were forced to use both clocks, and to trust that the vendor got the analog portions of the PLL right, I would write a simplified rtl model that just trusted the vendor specs. I don't think a gate sim would make me feel better. Maybe a SPICE sim would ;) This is analogous to the case of a two flop bit synchronizer. I might simplify a model that gave me 'U' outputs for setup violations because I 'believe" the synchronizer will work well enough. > ... I swapped-in > much simpler, but perfectly adequate in-house models and > got x10 simulation speedup. Sounds reasonable to me. -- Mike TreselerArticle: 136460
Jonathan Bromley wrote: > I swapped-in > much simpler, but perfectly adequate in-house models and > got x10 simulation speedup. Ditto! Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 136461
On Nov 18, 7:44 am, "Michael Brown" <s...@signature.below> wrote: > JohnOD wrote: > > I'm trying to get a Xilinx Spartan-3E Starter Kit to work with a Linux > > computer (Fedora 9), using ISE 10.1. > [...] > > See:http://rmdir.de/~michael/xilinx/ > [...] > > I couldn't get it working on a Debian box, but Fedora is much closer to RHEL > than Debian is so there's a pretty good chance it'll take. I have successfully got Xilinx 9.2i working on Fedora 8 with the cable driver given in the first link Michael posted. I've been keeping a note of how I got such things working in case I need to reinstall. I've copied the relevant commands below - they should be similar if not identical for F9 and ISE 10.1. You will need to be the root user in order to run a number of these commands. ---------------------------------------- Build and move the cable driver: tar -xzf usb-driver-HEAD.tar.gz cd usb-driver make cp libusb-driver.so /usr/local/lib Make sure the fxload package is installed (if it is the executable / sbin/fxload will exist). Setup udev and allow cable firmware to be updated (this does the actions in the 'Notes for the USB cable' section of the USB driver readme). Substitute path to Xilinx as appropriate: cd /opt/Xilinx92i/bin/lin source ./setup_pcusb If you had a programming cable already plugged in, unplug it and plug it back in again so these changes take effect. You can check this by running /sbin/lsusb which should give the cable ID as 03fd:0008. Create a startup script, based upon the Xilinx-provided script, to load the cable driver prior to starting ISE: cp /opt/Xilinx92i/settings.sh /usr/local/bin/startise echo "export LD_PRELOAD=/usr/local/lib/libusb-driver.so" >> /usr/local/ bin/startise echo "exec ise" >> /usr/local/bin/startise chmod +x /usr/local/bin/startise You should now be able to run ISE as a regular user with the command 'startise'. ---------------------------------------- Hope this information helps you. BlairArticle: 136462
manual prelinking with libusb is not needed anymore with 10.1. there is a environment variable to make ise/impact/chipscope/... automatically use libusb instead of windrvr6 see http://www.xilinx.com/support/answers/29310.htm > If you had a programming cable already plugged in, unplug it and plug > it back in again so these changes take effect. You can check this by > running /sbin/lsusb which should give the cable ID as 03fd:0008. 03fd:0008 is for DLC9 DLC10 needs 03fd:0013 just copy the xusbdfwu.rules from your xilinx directory to your udev rules.d directory... > > cp /opt/Xilinx92i/settings.sh /usr/local/bin/startise > echo "export LD_PRELOAD=/usr/local/lib/libusb-driver.so" >> /usr/local/ > bin/startise > echo "exec ise" >> /usr/local/bin/startise > chmod +x /usr/local/bin/startise > > You should now be able to run ISE as a regular user with the command > 'startise'. > > ---------------------------------------- > > Hope this information helps you. > > BlairArticle: 136463
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote in news:5ra3i41ksqpt0r432qv6tulvijk28s7qta@4ax.com: > Every cloud has a silver lining, but it seems > every rose has its thorns too. > > PLLs/DCMs/DLLs (or whatever your favourite FPGA > happens to offer) provide a wonderful way to create > multiplied-up clocks within the device. What's more, > you can line up the active clock edges so closely > that you can treat the x1 and xN clock domains as > if they were one single clock domain; hold times > can be avoided when crossing the boundary in either > direction. > > Until recently I've always avoided taking advantage > of this, and have treated the x1 and xN clock domains > as if they were asynchronous, using FIFOs or whatever > to convey things across the boundary. But in a recent > client engagement I was faced with a design in which > a x2 and x4 clock, from the same PLL, were used in > a completely sensible way as if they were in the same > clock domain as the original x1 clock. The TimeQuest > timing analyzer (for it was Brand A that was in use > on this occasion) was quite happy to deal with these > crossings, giving clear-headed and (as it turned out) > accurate reports of what was going on. There is no > doubt that this is cool. > > However, it's not so cool in RTL simulation. The > PLL simulation models, not too surprisingly, > introduce some delta delays between the > nominally coincident clock edges. Consequently > I get everything working when going in one direction > (from fast clock to slow clock, as it turns out) > but I get shoot-through behaviour, the RTL equivalent > of a hold time violation, when crossing from slow to > fast clock; data is arriving one or more delta cycles > *before* the clock. > > We've easily enough got around this for the present > design, but I'd love to know what all you seasoned > PLL/DCM users out there do about it. Do you > introduce small non-zero time delays in all the > signals crossing the clock domains, so that it all > works in simulation? Do you treat the various > clock domains as if they were asynchronous, thereby > losing one of the nicest benefits of the PLLs? Or > do you simply accept that it's necessary to do timing > simulation in order to see what will really happen? > > This is partly a plague of VHDL RTL sim (hence the > posting to c.l.vhdl as well); in Verilog you can > model clock gating and PLL-ish behaviour with "less" > zero delay than the nonblocking assignments to your > flip-flops, by taking care to use blocking assignment > in all your clock paths. I have not yet tried the > Verilog simulation models for the PLLs to see whether > that makes any difference. > > One further whinge: I haven't tried this in Brand X > recently, but the Altera PLL models are spectacularly > inefficient for RTL simulation. In our modest-size > project - think SDRAM controller, a few FIFOs occupying > most of the blockRAM, and a fairly small bunch of > additional logic - the two PLLs are responsible for > at least 90% of the simulation time - OUCH. I swapped-in > much simpler, but perfectly adequate in-house models and > got x10 simulation speedup. > > Opinions/rants/insults welcomed. Thanks in advance. I use a behavioural clock generator that has 0 skew outputs, specifically to avoid many of the problems you observe with vendors' PLLs. Yet another problem: Some PLL models can't accept jitter. I recently had an Altera PLL tell me that it was unlocking because my input clock was changing frequency. My input clock had a stable frequency, but with a jitter equal to the timing resolution of the simulator (which is necessary to simulate clocks that have a period that isn't integer multiple of the resolution, e.g. 155.52MHz with a 1ns resolution). Regards, AllanArticle: 136464
On Nov 17, 3:38=A0pm, Mike Treseler <mtrese...@gmail.com> wrote: > Jonathan Bromley wrote: > > We've easily enough got around this for the present > > design, but I'd love to know what all you seasoned > > PLL/DCM users out there do about it. =A0Do you > > introduce small non-zero time delays in all the > > signals crossing the clock domains, so that it all > > works in simulation? =A0Do you treat the various > > clock domains as if they were asynchronous, thereby > > losing one of the nicest benefits of the PLLs? =A0Or > > do you simply accept that it's necessary to do timing > > simulation in order to see what will really happen? > > Naturally, I would prefer to fix up the design > to use a single clock or another "known good" > synchronization scheme. > > If I were forced to use both clocks, > and to trust that the vendor got the > analog portions of the PLL right, I would > write a simplified rtl model that > just trusted the vendor specs. > I don't think a gate sim would make me feel better. > Maybe a SPICE sim would ;) > > This is analogous to the case of a > two flop bit synchronizer. I might simplify > a model that gave me 'U' outputs for > setup violations because I 'believe" > the synchronizer will work well enough. > > > ... I swapped-in > > much simpler, but perfectly adequate in-house models and > > got x10 simulation speedup. > > Sounds reasonable to me. > > =A0 =A0-- Mike Treseler Not quite where Jonathan was headed with this, but: Applying "standard" synchronization techniques to not-quite- asynchronous interfaces can and has caused problems. With truly asynchronous interfaces, the probability that an input will fall within the narrow region that causes metastability lasting long enough to be a problem (with two flop synchronizers) is extremely rare. However, if the two clock domains are related, such an event can happen much more often (or never at all). If they do happen (i.e. the stars align...) they will happen much more frequently (i.e. the stars will stay aligned). If at all possible I would take steps to ensure that either the clocks are related and a fully synchronous interface is employed, or that they are not related and asynchronous interface techniques are employed. Failing that, a three stage synchronizer should be considered. I have solved the simulation problem in the past by running the main clock through the same module where the DCM is, and providing a 1:1 clock output that is delayed (RTL) for the same number of delta cycles as the DCM delays its output. That delayed 1:1 output is used to drive the rest of the design. This is not always easy, especially when the DCM would otherwise best be buried down at an appropriate level of hierarchy along with it's associated functionality. AndyArticle: 136465
On Nov 16, 2:17=A0am, John Adair <g...@enterpoint.co.uk> wrote: [snip[ > The Actel and Silicon Blue offerings look quite good but either a > small choice, or none, in non-QFN and non-BGA packages probably means > these guys just want the high volume markets and the little guy once > more isn't of interest. Some support for TQ144 or PQ208 would gain > these parts some popularity. > > John Adair > Enterpoint Ltd. SiliconBlue does have a VQ100 package on their roadmap, although I don't know if it's available today or not. -- Steve Knapp Prevailing Technology, Inc. www.preavailing-technology.comArticle: 136466
On Nov 17, 3:45 am, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2008-11-14, jleslie48 <j...@jonathanleslie.com> wrote: > > > need to know where to start to get RS232 comm's working, and the led's > > blinking. > > > I was kinda hoping when I opened the box to my new XUPV2P: > > >http://www.xilinx.com/products/devkits/XUPV2P.htm > > > there would be some basic, hello world programs templates to play > > with, and a demo program so that > > I could have the board send and receive messages on the DB9 > > connector. I can't seem to locate anything of the sort. Does > > anybody have a good tutorial for my first program? > > From your post I'm uncertain whether you have prior experience with > FPGAs or not. Since you are talking about a hello world program and > RS232 I suspect that you are interested in using the PPC405 processors > in the FPGA. If so, I would strongly recommend the EDK to you. > > However, if you are not interested in the EDK but still want to use the > processors it is possible to do so. I have an example design for this > at my homepage athttp://www.da.isy.liu.se/~ehliar/stuff/which worked > the last time I tried it (a year or so ago). (Search for PPC405 on the > page.) The UCF file in this design is made for the XUPV2P board. > > However, if you are not interested in using the PPC405 but still want > to use the RS232 port I would recommend the RS232-tutorial over atwww.fpga4fun.com. > > Good luck! > > /Andreas Ok, I've reviewed the two links. They do a nice job of explaining the theory, and even give some nice snippets of code; I'm really looking for a from start to finish example of an fpga program that can be loaded and run. the fpga4fun.com rs232 page had a zip file with two .v files and a .c program. I assume I'm supposed to unpack those 3 files, and then use them somehow... A good "hello world" programming example, starts with unpacking the zip file, and then step by step opens the building programs, shows you the buttons/switches to call, shows you what files are generated, walks you through powering up, downloading the exe image, and then running the program and verifying that it is functioning correctly. Are there any "soup to nuts" test programs for the xilinx evaluation kit out there???Article: 136467
Many thanks to all three of you who replied... all of your answers were helpful, and I managed to get it working. (This was a Spartan-3E Starter Kit working on Fedora 9.) I really appreciate the time you took. Never would have managed it without your help! Cheers, John On Nov 18, 4:08=A0am, blair.bonn...@gmail.com wrote: > On Nov 18, 7:44 am, "Michael Brown" <s...@signature.below> wrote: > > > JohnOD wrote: > > > I'm trying to get a Xilinx Spartan-3E Starter Kit to work with a Linu= x > > > computer (Fedora 9), using ISE 10.1. > > [...] > > > See:http://rmdir.de/~michael/xilinx/ > > [...] > > > I couldn't get it working on a Debian box, but Fedora is much closer to= RHEL > > than Debian is so there's a pretty good chance it'll take. > > I have successfully got Xilinx 9.2i working on Fedora 8 with the cable > driver given in the first link Michael posted. I've been keeping a > note of how I got such things working in case I need to reinstall. > I've copied the relevant commands below - they should be similar if > not identical for F9 and ISE 10.1. You will need to be the root user > in order to run a number of these commands. > > ---------------------------------------- > > Build and move the cable driver: > tar -xzf usb-driver-HEAD.tar.gz > cd usb-driver > make > cp libusb-driver.so /usr/local/lib > > Make sure the fxload package is installed (if it is the executable / > sbin/fxload will exist). Setup udev and allow cable firmware to be > updated (this does the actions in the 'Notes for the USB cable' > section of the USB driver readme). Substitute path to Xilinx as > appropriate: > cd /opt/Xilinx92i/bin/lin > source ./setup_pcusb > > If you had a programming cable already plugged in, unplug it and plug > it back in again so these changes take effect. You can check this by > running /sbin/lsusb which should give the cable ID as 03fd:0008. > Create a startup script, based upon the Xilinx-provided script, to > load the cable driver prior to starting ISE: > > cp /opt/Xilinx92i/settings.sh /usr/local/bin/startise > echo "export LD_PRELOAD=3D/usr/local/lib/libusb-driver.so" >> /usr/local/ > bin/startise > echo "exec ise" >> /usr/local/bin/startise > chmod +x /usr/local/bin/startise > > You should now be able to run ISE as a regular user with the command > 'startise'. > > ---------------------------------------- > > Hope this information helps you. > > BlairArticle: 136468
On Tue, 18 Nov 2008 06:36:22 -0800 (PST), Andy wrote: >Applying "standard" synchronization techniques to not-quite- >asynchronous interfaces can and has caused problems. With truly >asynchronous interfaces, the probability that an input will fall >within the narrow region that causes metastability lasting long enough >to be a problem (with two flop synchronizers) is extremely rare. >However, if the two clock domains are related, such an event can >happen much more often (or never at all). If they do happen (i.e. the >stars align...) they will happen much more frequently (i.e. the stars >will stay aligned). Yes. Worse still, you can easily lose track of which source clock gave rise to the datum on a given destination clock, because the quasi-static phase relationship between the two clocks is unknown and highly variable from one instance of the design to another. I suffered this on the same recent project: part of the design was, for very good reasons, clocked by exactly the main system clock that had been through a chain of external buffers (thereby allowing the design to track temperature/voltage/process variations in the behaviour of other signals that went through similar external buffers). I had the devil of a time trying to persuade the designers that we needed to know the window within which the delayed clock would fall, so that we could decide which edge of it belonged with which edge of the master clock. Of course, no-one had thought to provide a synchronous "data valid" signal that could have been used to track this. >I have solved the simulation problem in the past by running the main >clock through the same module where the DCM is, and providing a 1:1 >clock output that is delayed (RTL) for the same number of delta cycles >as the DCM delays its output. That delayed 1:1 output is used to drive >the rest of the design. This is not always easy, especially when the >DCM would otherwise best be buried down at an appropriate level of >hierarchy along with it's associated functionality. Perfect summary of the issues I was hoping to raise. Thanks. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 136469
Try using alt_printf (instead of printf) for printing statements to a
terminal screen if you want a smaller footprint for a Nios project.
This is a lighter-weight version of printf that's optimized for Nios
(also has fewer features, but works fine for my UART interfacing).
Also try checking the "reduced device drivers" and "lightweight device
drivers API" in the project settings. This should help. My project
was in Nios IDE 6.1, so I can't speak to the newer toolsets, but this
worked for me.
On Nov 14, 2:23=A0am, Bas Laarhoven <s...@xs4all.nl> wrote:
> fl wrote:
> > On Nov 13, 2:01 pm, Frank Buss <f...@frank-buss.de> wrote:
> >> fl wrote:
> >>> Hi,
> >>> I am trying to use Nios II with one Stratix II (2S60) DSP board, not
> >>> the Nios board. Even to use Nios /f in the simplest hello example, th=
e
> >>> following error message is still there. What is the problem? Thanks
> >>> all. BTW, Using Quartus 7.2 subscription.
> >>> **** Build of configuration Debug for project hello_world_1 ****
> >> Try release mode. You can switch this somewhere in the project setting=
s in
> >> Eclipse ("Properties" right-click menu item on the project).
>
> >> --
> >> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-=
systems.de
> > Thanks. I change mode from Debug to Release. Although the memory
> > requirement is smaller (from 40K to 14K), it still has the same error
> > message.
> > The program is only a simple Hello_world. It should not be so memory
> > hungry.
> > Thanks,
>
> > **** Build of configuration Release for project hello_world_1 ****
>
> > make -s all includes
> > Compiling hello_world.c...
> > Linking hello_world_1.elf...
> > /cygdrive/c/altera/72/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/
> > bin/../lib/gcc/nios2-elf/3.4.1/../../../../nios2-elf/bin/ld: region
> > onchip_mem is full (hello_world_1.elf section .text). Region needs to
> > be 14136 bytes larger.
>
> This message indicates that the linker thinks you've got no memory _at
> all_ for the text section! So memory is not to small, but probably badly
> mapped. I suggest you look at (and compare) the linker configuration and
> SOPC/NIOS configuration.
>
> -- Bas
>
> > /cygdrive/c/altera/72/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/
> > bin/../lib/gcc/nios2-elf/3.4.1/../../../../nios2-elf/bin/ld: region
> > onchip_mem is full (hello_world_1.elf section .rwdata). Region needs
> > to be 2676 bytes larger.
> > /cygdrive/c/altera/72/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/
> > bin/../lib/gcc/nios2-elf/3.4.1/../../../../nios2-elf/bin/ld:
> > section .rodata [00002020 -> 00002067] overlaps section .exceptions
> > [00002020 -> 000021c7]
> > /cygdrive/c/altera/72/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/
> > bin/../lib/gcc/nios2-elf/3.4.1/../../../../nios2-elf/bin/ld:
> > section .rwdata [00002068 -> 00003a73] overlaps section .exceptions
> > [00002020 -> 000021c7]
> > /cygdrive/c/altera/72/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/
> > bin/../lib/gcc/nios2-elf/3.4.1/../../../../nios2-elf/bin/ld:
> > section .bss [00002020 -> 00002233] overlaps section .exceptions
> > [00002020 -> 000021c7]
> > /cygdrive/c/altera/72/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/
> > bin/../lib/gcc/nios2-elf/3.4.1/../../../../nios2-elf/lib/mhw-mulx/
> > mcustom-fpu-cfg=3D60-1//libc.a(sbrkr.o)(.text+0x14): In function
> > `_sbrk_r':
> > /build/nios2eds-gnutools-win32-7.2/bin/nios2-gnutools/src/newlib/
> > newlib/libc/reent/sbrkr.c:59: Unable to reach errno (at 0x00002020)
> > from the global pointer (at 0x0000ba1c) because the offset (-39420) is
> > out of the allowed range, -32678 to 32767.
>
> > collect2: ld returned 1 exit status
> > make: *** [hello_world_1.elf] Error 1
> > Build completed in 8.297 seconds
Article: 136470"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:jgn5i4hgvo65a0stlpsfsmlo6de0q1lugs@4ax.com... > >>I have solved the simulation problem in the past by running the main >>clock through the same module where the DCM is, and providing a 1:1 >>clock output that is delayed (RTL) for the same number of delta cycles >>as the DCM delays its output. That delayed 1:1 output is used to drive >>the rest of the design. This is not always easy, especially when the >>DCM would otherwise best be buried down at an appropriate level of >>hierarchy along with it's associated functionality. > > Perfect summary of the issues I was hoping to raise. Thanks. > -- > Jonathan Bromley, Consultant > It also seems that if the design only uses the outputs from the DCM only, i.e. CLK0, CLKDV, CLK2X, which is the way they are 'meant' to be used, then they are already aligned. Problems arise when folks subsequently add stuff to their VHDL like:- my_clock <= his_clock; This assignment is optimised away in real life, but in the simulation, my_clock is now a delta later than his_clock, and maybe no longer aligns with his_clock_2X. HTH., Syms.Article: 136471
I am trying to use spartan 3A dap fpga for a robotic application. and i have no idea about the memory used in the fpga. so any information about the memory types and about using them will be highly appreciatedArticle: 136472
HI All, I am using a Spartan3 starter board from digilent. The inputs that I am feeding to the board are two things: a pulser generator and a reference signal. The pulser has a maximum repition rate (periodic) at 50Mhz , Pulse pair resolution 20ns, Minimum output pulse width 10ns, TTL. The reference signal runs at 50.125Khz , ~4.5V. Can you explain if the inputs will damage my board. What should I do externally to prevent any damage to the board ? Is there anything I must take into account. ThanksArticle: 136473
On Nov 18, 4:29=A0pm, uraniumore...@gmail.com wrote: > HI All, > > I am using a Spartan3 starter board from digilent. The inputs that I > am feeding to the board are two things: a pulser generator and a > reference signal. The pulser has a maximum repition rate (periodic) at > 50Mhz , Pulse pair resolution 20ns, Minimum output pulse width 10ns, > TTL. The reference signal runs at 50.125Khz , ~4.5V. Can you explain > if the inputs will damage my board. What should I do externally to > prevent any damage to the board ? Is there anything I must take into > account. > > Thanks Xilinx has app notes on driving 5V TTL signals into the Spartan 3 series. For devices with integrated clamping diodes to Vcco, they suggest using a series resistor to limit the clamp current to less than 10 mA IIRC. However you should be aware that the timing can be adversely affected when the input voltage goes above Vcco. So I wouldn't recommend this method on a clock signal fro example. There are a number of logic families that can take 5V inputs and generate 3.3V or lower CMOS level outputs. If you're worried about propagation delay you can also get the "zero propagation delay" switches which consist of a FET whose gate voltage limits the high voltage pass-through. These are often used as "hot plug" buffers.Article: 136474
On Nov 18, 3:34=A0pm, denish <dinesh.twanab...@gmail.com> wrote: > =A0I am trying to use spartan 3A dap fpga for a robotic application. and > i have no idea about the memory used in the fpga. so any information > about the memory types and about using them will =A0be highly appreciated The Xilinx datasheet for your part will tell you how much memory it has in terms of kilobits of block RAM (integrated dual-port memory) and distributed RAM (memory you can build from the fabric while losing the logic those cells would otherwise provide). Xilinx also has Appnotes and User Guides which go into more detail on the memory. If you browse the Xilinx site under Documentation, Device family, etc. you should find all of the documents related to Spartan 3A DSP.
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