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
"Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message
news:f1ci9j$80t$1@news.lysator.liu.se...
> On 2007-05-03, Andy <jonesandy@comcast.net> wrote:
>
> So I'd summarize the advantages/disadvantages like this:
>
> wait until rising_edge(clk):
> + No sensitivity list to worry about
> + No asynchronous behaviour to worry about
> - Might lead students to use wait in ways they shouldn't
>
> if rising_edge(clk) then:
> + No wait statement
> + A bit more general
> - Fully legal to create asynchronous logic, including latches
> - Sensitivity list to worry about
Those are by no means the only options. For example:
process (clock)
begin
if rising_edge(clock) then
-- Put your RTL code in here
if reset = '1' then
-- Put the code that resets any signals that need resetting in here
end if;
end if;
end process;
Pros/cons:
+ No wait statement
+ Completely general
+ No asynchronous behaviour to worry about
+ No sensitivity list to worry about
+ Efficient (sync) resets for signals that need them
but with no penalty for signals that don't
- ???
-Ben-
Article: 118776
"Antti" <Antti.Lukats@xilant.com> wrote in message
news:1178200918.376020.170930@u30g2000hsc.googlegroups.com...
On 2 Mai, 19:44, dalai lamah <antonio12...@hotmail.com> wrote:
> Un bel giorno Antti digiṭ:
> > Actually some bugs and missing features - especially in the user
> > interface
> > - are quite funny, for example the editor that hangs forever if you try
> > to
> > use the dead keys (i.e.http://en.wikipedia.org/wiki/Dead_key). Or is it
> > just me?
>
> My god, you are right!
> Just tried out in ISE 9.1 in ucf editor ... it really hangs !!!!
>
> Well the workaround is simple, not to use dead keys. But its really
> hard to imagine how some company is able to develop software with such
> bugs!
This might, of course, be an underlying bug in the Qt widgets that the
ISE/XPS GUIs use... what OS are you talking about? I know that many of
Microsoft's own programs have (more minor) problems with dead-key handling;
I ended up turning off the International keyboard features because they just
didn't work properly in too many applications... :(
> So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need
> kill and loose changes!), is minor, some other issues with EDK 9.1 are
> not:
Needless to say, I know lots of people who are succesfully running EDK 9.1i
and ISE 9.1i, with and without the various service packs and IP updates, who
haven't reported any problems at all. I am one of them. Perhaps the setup of
my environment is much simpler that yours?
Cheers,
-Ben-
Article: 118777As far as I've heard/seen in large companies with regulated coding styles, the wait statement version of a DFF is considered to be sloppy for readability maintainability purposes. tick-event is considered a much cleaner way of coding a DFF. As for the original question: Buy a book on synthesizable VHDL and lookup "counter" in the index But it will go something along the lines of if count = "00000000" then enable <= '1'; else enable <= '0'; end if; Obviously that needs to be within a process and all that jazz. But definately buy a good book on SYNTHESIZABLE vhdl.... 70% of the language is non- synthesizable, not knowing which parts that is makes it very useless for you as a designer. Wait statements, time, etc.. would have been included in chapter 1 just about of any decent synthesis book. When I took my vhdl class in undergrad we used VHDL Primer - which in retrospect is a poor book in terms of seperating synthesizable from non-synthesizable constructs. I used the andrew rushton in a graduate class recently - much, much better. On May 3, 7:50 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > On 2007-05-03, Andy <jonesa...@comcast.net> wrote: > > > You cannot wait for TIME in synthesizable code. You can wait until > > rising_edge(clk)! Not usually the best coding style, but it can be > > done and is accepted by most synthesis tools. > > I was also of the opinion that it wasn't a very good coding style but > after a couple of years of basic VHDL teaching I think it is actually > better to say that a sequential process looks like this: > > process > begin -- process > wait until rising_edge(clk); > -- Some code... > end process; > > The "standard" alternative is this: > > process (clk) > begin -- process > if clk'event and clk = '1' then -- rising clock edge > -- Some code... > end if; > end process; > > The problem with the second one is that first time students are likely > to produce something like: > > process (clk) > begin -- process > if rst = '1' then > foo <= (others => '0'); > end if; > > if clk'event and clk = '1' then -- rising clock edge > -- Some code... > else > somethingelse <= '0'; > end if; > end process; > > This kind of unholy synchronous/asynchronous process will usually be > accepted by the synthesis tool and work badly, if at all whereas it > is not possible to create any asynchronous behaviour if the first version > is used. (Or rather, synthesis tools will not allow it) > > So I'd summarize the advantages/disadvantages like this: > > wait until rising_edge(clk): > + No sensitivity list to worry about > + No asynchronous behaviour to worry about > - Might lead students to use wait in ways they shouldn't > > if rising_edge(clk) then: > + No wait statement > + A bit more general > - Fully legal to create asynchronous logic, including latches > - Sensitivity list to worry about > > /AndreasArticle: 118778
Incorrect, the above example is not in fact easy to synthesize, at least not in the fashion the person presumably wanted it to synthesize... first off.. it need to be in a process... "wait until" makes no sense, even for a testbench, in the context of a concurrent statement so lets assume it was meant to be put in a process: process begin signal <= '0'; wait until count = 0; signal <= '1'; end process; even in simulation, the signal will never change from a 0. it will set it to a '1', the activity on signal will reactivate the process and it will in 1-delta time set back to a 0, never changing in "real" (non-delta) time! sure the synthesizer could tie 'signal' to ground, but i dont think that was the intent... so lets give the person the benefit of the doubt... write it like it was a testbench signal <= '0'; wait until count = 0; signal <= '1'; wait; pause the process indefinately (as far as simulation is concerned) after it sets signal to '1'. but wait... count is a flip flop.. so we compare count with 0, AND the output of the comparison with a '1' and that's our signal, right? but wait what happens on reset? the flop is reset, and signal goes back to a '0'... probably what we WANTED, but not what our code describes, and not what a simulator would tell you it's gonna do! so to make this match simulation, signal must go into a latch, a real, honest, level- sensitive latch... not an enabled DFF, because that would clear on reset, which according to our code is NOT what we wanted.... but that latch is a timing nightmare and almost NEVER recommended in an FPGA... probably not what we actually wanted, but indeed the only way our synthesizer can accurately synthesize the code we wrote to match simulation (i.e. match what our code describes) Still think this is a deficiency of the tool?? > Indeed, you can't. But I consider this to be a deficiency of the > tools. The above example is > easy to synthesize. There have been academic proofs of concept decades > ago. > Essentially you only need to add a state per wait statement. > > Kolja Sulimma- Hide quoted text - > > - Show quoted text -Article: 118779
On Apr 26, 12:03 pm, Newman <newman5...@yahoo.com> wrote: > On Apr 25, 11:37 am, Roman <plyas...@googlemail.com> wrote: > > > > > Hello! > > > I am using a board with Virtex4 PPC405, external asynchronousSRAM > > memory and EDK 8.2i. If application program resides in BRAM and I want > > to write and read fromSRAM, it is only possible if there is > > instruction and data cache enebled and I add XCache_EnableCache in the > > beginning of the code. So far it works. Then I tried to run > > application fromSRAM. So I generated linker script telling that the > > program should be inSRAM. After I launched XMD and entered > > > dow executable.elf > > run > > > it didn't work. When I tried to read downloaded code by mrd command > > fromSRAM, it showed zero values. > > Furthermore, I tried to explicitly write a value toSRAMwith mwr > > command and read it afterwards, it showed zero value again. > > > So I thought the problem is that cache is still not enabled (because > > code is not running and XCache_EnableCache function was not executed). > > Then I set in XMD debug options "Set XMD memory map for PPC405 > > features" where it is possible to enable caches, but it didn't help. > > > Parameter C_INCLUDE_BURST_CACHELN_SUPPORT in .mhs file is set to 1. > > > Does anybody have any suggestions what it could be? > > Thanks in advance! > > > Best regards > > Roman > > One way to track down the problem is to look at thesramlines with > chipscope stimulating it with mwr, mrd. It could be that you were > fooled in the first example, and data reads and writes looked good > because they were being accessed via the cache only, and not beiIng > posted to thesram. > > I believe chipscope is a good investment for what you are doing. A > free evaluation is available from Xilinx. > > Newman Thanks a lot! There was a problem with physical connection to SRAM.Article: 118780
Ben Jones schrieb: > "Antti" <Antti.Lukats@xilant.com> wrote in message > news:1178200918.376020.170930@u30g2000hsc.googlegroups.com... > On 2 Mai, 19:44, dalai lamah <antonio12...@hotmail.com> wrote: > > Un bel giorno Antti digit=F2: > > > > Actually some bugs and missing features - especially in the user > > > interface > > > - are quite funny, for example the editor that hangs forever if you t= ry > > > to > > > use the dead keys (i.e.http://en.wikipedia.org/wiki/Dead_key). Or is = it > > > just me? > > > > My god, you are right! > > Just tried out in ISE 9.1 in ucf editor ... it really hangs !!!! > > > > Well the workaround is simple, not to use dead keys. But its really > > hard to imagine how some company is able to develop software with such > > bugs! > > This might, of course, be an underlying bug in the Qt widgets that the > ISE/XPS GUIs use... what OS are you talking about? I know that many of > Microsoft's own programs have (more minor) problems with dead-key handlin= g; > I ended up turning off the International keyboard features because they j= ust > didn't work properly in too many applications... :( > > > So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need > > kill and loose changes!), is minor, some other issues with EDK 9.1 are > > not: > > Needless to say, I know lots of people who are succesfully running EDK 9.= 1i > and ISE 9.1i, with and without the various service packs and IP updates, = who > haven't reported any problems at all. I am one of them. Perhaps the setup= of > my environment is much simpler that yours? > > Cheers, > > -Ben- Hi Ben, agreed, there are very likely plenty of EDK 9.1 installation that work OK. my own experience so far is 3 out 3 have problems, either minor or showstoppers. 3 out of 3 is too small criteria of course. but I have to find workaround to get those 3 all working also :(, 1 is ok 2 still refuse to work properly. BTW the % amount of succesful Xilinx software tool installations within Xilinx and outside may be quite different. actually I think the amount of success (installing Xilinx software) inside Xilinx should not be counted at all, only the success-failure ration for installations done outside. AnttiArticle: 118781
On Thu, 03 May 2007 08:41:34 +0100, Flash Gordon <spam@flash-gordon.me.uk> wrote: >John Larkin wrote, On 03/05/07 01:09: >> On Wed, 02 May 2007 22:59:08 +0100, Flash Gordon > ><snip> > >>> Why do you think it reasonable for us to have to put up with >>> inappropriate cross-posts and not for you to put up with polite requests >>> to stop the cross-posts? >> >> You're right, engineers and programmers should communicate as seldom >> as possible. > >OK, so you are incapable of reading, understanding or answering >questions even when those you are responding to are staying polite. > >For the record, I have never said engineers and programmers should not >communicate, and I have worked very closely with HW people in the past >where it was appropriate. However, that still does not, and never can >make, posting stuff in comp.lang.c about how to design the HW >appropriate in comp.lang.c > >Note that the only comment I got when asking if posting physics >questions to the other groups was a post saying one of the groups was >already being invaded by trolls, not a response saying that it would be >acceptable. So you obviously only care about the topicality of YOUR >group(s) and sod everybody else. s.e.d. routinely discusses electronic circuit design, thermal design, mechanics and materials properties, manufacturing and economic issues, fpga design, uPs/firmware/dsp/numeric algorithms, operating systems, and computer languages. In a real electronic design, all these must be accounted for and all trade off against the others. If switches bounce, there are a number of solutions, the cheapest and most reliable (assuming no coding bugs!) being to do it in software. I'm always interested in how hermetic some disciplines are, how intense some programmers are to keep the programming pure, to abstract away the real world, and to do their best to know nothing about the environment their programs actually live in; hence comments like "switch debouncing is best done in hardware." I mean, if all you know is programming, how do you find a problem to program? Do you depend on an exhaustive specification that's created by someone else who understands the end application, so you don't have to get involved? Would you ever look at a switch datasheet to see how long it might bounce? JohnArticle: 118782
Ben Jones schrieb: > "Antti" <Antti.Lukats@xilant.com> wrote in message [] > This might, of course, be an underlying bug in the Qt widgets that the > ISE/XPS GUIs use... what OS are you talking about? I know that many of > Microsoft's own programs have (more minor) problems with dead-key handling; > I ended up turning off the International keyboard features because they just > didn't work properly in too many applications... :( > > > So while the dead-keys in text editor HANG PROJECT NAVIGATOR (need > > kill and loose changes!), is minor, some other issues with EDK 9.1 are > > not: > > Needless to say, I know lots of people who are succesfully running EDK 9.1i > and ISE 9.1i, with and without the various service packs and IP updates, who > haven't reported any problems at all. I am one of them. Perhaps the setup of > my environment is much simpler that yours? > > Cheers, > > -Ben- Ben, there are NO EXCUSES for bad software. if there problems are Qt widgets, then: 1) fix the problems 2) seek help 3) stop using Qt widgets if the problems are related to cygwin, then 1) fix the problems 2) seek help 3) stop using cygwin now, to my 3 EDK installations: issue 1) is fixed issue 2) - I have just been able to trace the problem to make version issue! , this is nothing new. it happened once before with some Xilinx updates, so it looks that it just re-appeared.. think I can fix it, so after that I can say that 2 out 3 work AFTER fixing them post-install AnttiArticle: 118783
On May 2, 4:15 am, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote: > comp.arch.fpga wrote: > > > What do you need the per pin configuration for? The pullups are > > > extremely > > week. (5uA to 200uA for Virtex-4). I can't imagine a digital > > application that > > will be disturbed by that. > > The board uses a with a Spartan-3E. The data sheet suggest the pull down > is 34K5 (Table 77 - ds312). I guess that's not too strong. > > However, I'd prefer the option to control the pull resistors on a > per-pin basis. It just seems to me a 'better' way of doing things. > > Thanks for the suggestions > Andy You should be able to alter the UCF to add the pull-up / pull-downs, though the resistor is permanently enabled after configuration. (you can't control it from the fabric) You can use this feature to eliminate external resistors with great effect. For example, I have a small add-in board that doesn't supply a proper VCC, so I use the internal pull-up to keep the reset line high, and use a switch to short the circuit to ground. Perhaps not the safest circuit, but it works. Of course, if the peripheral really is unused, and you just want to keep the device in a low-power/safe state, why not just drive the I/O directly from the VHDL? For example, right now I'm using a ComBlock board that has no free-running oscillator connected to the FPGA. Instead, you have to get your clock from the USB PHY, which only produces said clock after you drive its SUSPENDN signal high. (Of course this signal is pulled low, so your firmware has to pull it high, then hold the DCMs in reset until the output clock is stable...) I just have a line in the VHDL that directly drives that signal high.Article: 118784
Ken, Just out of curiosity, what is your timeline on this project?? You've been asking about this for months on here! (That's what all your DDR interface questions were about, no?) There's all sorts of considerations here... What is your input data format? Composite video? RGB? etc.. Some sort of computer driven RGB input would probably be your simplest as you'll be receiving your three colors seperately and you can just sample them as 3 input streams. But you're gonna have lots of learning and educating yourself to do on sync timing and all that fun stuff - Keep in mind, most analog video signals were designed to be fairly crude signals to drive a big honking electromagnetic coil that certainly didnt respond anything close to the clock rate of your spartan. Therefore, putting them into the digital world in some sorta of useful form can be a bit tricky - basically you need to look for your syncs and count out to where your first pixel is supposed to be. What are your input & output resolutions? frame rates? If you're going 10x10 to 20x20 at 5 fps, I'd bet you could do that in a Spartan3... 640x480 input at a 60hz refresh, I don't really know - that's where you're going to have to sit down and run some calcuations. Go to your school's library and take out some books on image processing or multi-dimensional DSP... you're gonna need to learn some basic image processing first to get an idea of what operations need to be done before you can begin to grasp the size of the part you need. How accurate do your interpolations need to be? Think basic 1- dimensional DSP.. how do you upsample a signal? insert zeros between samples and LPF, right? Or do the same thing in the F-domain by zero padding the ends of the FFT and inverse-FFT'ing. Either of these methods in 2 dimensions is going to be a lot of computation and a lot of taking stuff in and out of memory in different orders. DDR memories like you to take stuff out in the same order you put them in... they slow down big time when you try to jump around.. So if you do this, you will need to some up with some clever methods of read out pieces from DDR in the incorrect order, and then re-reading from a local, smaller, block ram in the order you actually want. This will take careful planning and a lot of simulation, even an experienced designer would have a tricky time with this and probably get it wrong in simulation the first shot. If your up/down sampling doesn't need to be terribly accurate, this simplifies things. Consider a simple first order interpolation... look left, look right and figure out what goes in between. You would do the row dimension as the data flows in, just put two rows into memory at a time and then do your column dimension. Obviously, you will need to calculate bandwidth here and make sure you've got plenty enough (with margin!) on your memory. Also, remember that multiplication & division are tricky in the binary world. The spartan3 does have some built in multipliers. But for a school project consider limiting your scope to make your life a little easier. Maybe you only scale by powers of 2, so everything becomes a Left/Right shift instead of mult/div? Maybe you limit it even more, you take 640x480 60Hz in and you ouptut 1280x960 60Hz, and do nothing else. The fewer possible cases you need to accoutn for the more likely it will be to fit in a smaller part. Lastly, are you trying to do this on the spartan3 starter kit? becuase that has no video in, and only a crude video out (no DAC, you can just turn on and off the RGB pixels in combinations.. so 2^3 = 8 colors, of which 1 is black and 1 is white)... If you are building your own board you are going to be limitted by the size FPGA you can get in a quad flat pack part - i assume you dont have the facilities to do a BGA - and those QFPs are still VERY fine pitch to solder by hand. Let me know if you've found an eval board already that's suitable for this application, I;m curious - I don't think any of the digilent spartan boards have video input. Good luck On May 2, 9:49 pm, "Ken Soon" <c...@xilinx.com> wrote: > Hi > Just want to do a feasibility study on whether it is possible to design and > implement a video scaler on a Spartan 3E? > Well my tutor kind of came up with this proposal for a project of mine but > then on my tutor's side, he has experience with fpga but I'm not sure > whether he had designed video scaling so may not know the complexity of it. > > So, feasible? And with which chip as well? (in the best of best case, i hope > can use just a spartan starter kit :) )Article: 118785
"Paul" <pauljbennett@gmail.com> wrote in message
news:1178203259.251061.292370@u30g2000hsc.googlegroups.com...
> As far as I've heard/seen in large companies with regulated coding
> styles,
> the wait statement version of a DFF is considered to be sloppy for
> readability maintainability purposes. tick-event is considered a much
> cleaner way of coding a DFF.
Well, the IEEE rising_edge and falling_edge functions are standard practice
and for good reason. The 'event syntax is beyond obsolete...
-Ben-
Article: 118786CBFalconer wrote: > What baffles me is that here is a whole list of people complaining, > and not one of them sets the follow-up marker (except me). I am > wondering if there is something in the readers or servers involved. As I mentioned elsewhere, I don't feel it's appropriate. The only reason I see to set follow-ups is when attempting to move a thread to a new group (not in the original distribution). Setting follow-ups does nothing for where YOUR post appears. If it's not appropriate for replies to yours to appear in group X, then your post wasn't appropriate either. The correct action is to remove group X from your post's distribution. That's what I did in a couple of early, "please don't post replies to clc" messages. These, where we're discussing what I consider to be metatopics, retain clc (I added it back). BrianArticle: 118787
"Antti" <Antti.Lukats@xilant.com> wrote in message
news:1178205908.643579.42880@o5g2000hsb.googlegroups.com...
> there are NO EXCUSES for bad software.
It depends whether you call it an excuse (emotive) or a reason. Everything
happens for a reason. Explaining why something happens doesn't equate to
justification, in my view.
> if there problems are [X], then:
> 1) fix the problems
> 2) seek help
> 3) stop using [X]
That's obvious enough, but it presupposes that you (or one of your
customers) finds and reports the problem... luckily, we have plenty of
people like you who are more than happy to bring these things to our
attention!
Good luck with your remaining issues... :-\
-Ben-
Article: 118788I'm a fairly experienced user of Quartus but I've never considered using "blocks" in block design files i.e. my design hierarchy consists of only symbols with a mixture of Verilog and graphic design modules "underneath" each symbol. I have never seen a need to use them. My question is: does anyone routinely use blocks in their designs and what are the advantages/disadvantages of doing so? It seems to me that they must be there for a good reason. I just can't see what that reason is and i think I may be missing out on something potentially useful. When I say block I mean using the "block" tool not the "symbol" tool. Blocks are or can be connected together with "conduits" whereas I think symbols can only be connected with "bus" and "node" connections.Article: 118789
Ben Jones schrieb: > "Antti" <Antti.Lukats@xilant.com> wrote in message > news:1178205908.643579.42880@o5g2000hsb.googlegroups.com... > > > there are NO EXCUSES for bad software. > > It depends whether you call it an excuse (emotive) or a reason. Everything > happens for a reason. Explaining why something happens doesn't equate to > justification, in my view. > > > if there problems are [X], then: > > 1) fix the problems > > 2) seek help > > 3) stop using [X] > > That's obvious enough, but it presupposes that you (or one of your > customers) finds and reports the problem... luckily, we have plenty of > people like you who are more than happy to bring these things to our > attention! > > Good luck with your remaining issues... :-\ > > -Ben- eh, sure different opions. sure. I really think it would not be so difficult for Xilinx to manage their software development better . (you may have other opinion in this matter) AnttiArticle: 118790
Ben Jones schrieb: > "Antti" <Antti.Lukats@xilant.com> wrote in message > news:1178205908.643579.42880@o5g2000hsb.googlegroups.com... > > > there are NO EXCUSES for bad software. > > It depends whether you call it an excuse (emotive) or a reason. Everything > happens for a reason. Explaining why something happens doesn't equate to > justification, in my view. > > > if there problems are [X], then: > > 1) fix the problems > > 2) seek help > > 3) stop using [X] > > That's obvious enough, but it presupposes that you (or one of your > customers) finds and reports the problem... luckily, we have plenty of > people like you who are more than happy to bring these things to our > attention! > > Good luck with your remaining issues... :-\ > > -Ben- HAHAHA! 2 out of 3 EDK installations work now!!! :) had to copy MAKE.EXE from edk into cygwin dir. Xilinx should make another AR about this, or adjust the old one about this issue... AnttiArticle: 118791
On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote: > You should be able to alter the UCF to add the pull-up / pull-downs, > though the resistor is permanently enabled after configuration. (you > can't control it from the fabric) You can use this feature to > eliminate external resistors with great effect. For example, I have a > small add-in board that doesn't supply a proper VCC, so I use the > internal pull-up to keep the reset line high, and use a switch to > short the circuit to ground. Perhaps not the safest circuit, but it > works. Again the UCF method only works if the pin in question has a net attached to it, i.e. if it doesn't get removed from the project as unused. I don't know of any method in the UCF to refer to pins merely by location. So while you can put a line in the UCF like NET "Foo" LOC = AA12 | PULLUP ; as soon as the net Foo gets removed from the project the pullup resistor goes away, too.Article: 118792
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Williams wrote: > I am trying to install the Xilinx ISE WebPACK software on a vmware > virtual machine running RHEL4-WS. I made the machine and installed > RHEL from scratch (it works that far) an now I'm trying to install > the ISE WebPACK. > > The "setup" program starts up, displays the pretty banner and asks > me for the devices I want to support. I make my selections, and > click "Next". The puzzling thing is that the installer thinks there > are 0 MB available in the destination volume, and asks me if I want > to install anyhow. > > Has anybody been able to install on a vmware virtual machine? I'm > trying real hard to give everybody *exactly* what they want, but > I'm not getting what *I* want:-( Some progress. I found that the Web install crashes but the single- file-download works. It still complains that the target fs has 0MB available (utter nonsense) but it installs anyhow, without crashing. So the web install is just plain fubar. - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGOiS2rPt1Sc2b3ikRAkgjAKDJD2nkVCblCIdC4RFir9ggrq8D7QCfSNX9 m+YmJ0Se0aUy5PqhI2eGZu4= =cvr4 -----END PGP SIGNATURE-----Article: 118793
On May 3, 12:28 pm, Gabor <g...@alacron.com> wrote: > On May 3, 11:57 am, radarman <jsham...@gmail.com> wrote: > > > You should be able to alter the UCF to add the pull-up / pull-downs, > > though the resistor is permanently enabled after configuration. (you > > can't control it from the fabric) You can use this feature to > > eliminate external resistors with great effect. For example, I have a > > small add-in board that doesn't supply a proper VCC, so I use the > > internal pull-up to keep the reset line high, and use a switch to > > short the circuit to ground. Perhaps not the safest circuit, but it > > works. > > Again the UCF method only works if the pin in question has > a net attached to it, i.e. if it doesn't get removed from the > project as unused. I don't know of any method in the UCF > to refer to pins merely by location. So while you can put a > line in the UCF like > NET "Foo" LOC = AA12 | PULLUP ; > as soon as the net Foo gets removed from the project > the pullup resistor goes away, too. If the pin really is unused, and you really want that pin to float or stay at a DC level, then just add the appropriate net. Even something simple like dummy_net <= 'Z'; would cover it. Just check the FPGA editor to make sure you are really getting a permanently disabled tri- state buffer. Then, add the pullup/pulldown constraint to the UCF. Is there a reason you can't add a dummy net to the pin? I generally make a practice of assigning nets to all external I/O, and then tie them off in the top-level until they are used - just so I can control stuff like this. That way, I can finish the I/O constraints early on, and not have to worry about mucking with them later on. From rich@example.net Thu May 03 11:26:01 2007 Path: nlpi060.nbdc.sbc.com!newsdst02.news.prodigy.net!prodigy.com!newscon02.news.prodigy.net!prodigy.net!wns13feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc03.POSTED!dd653b87!not-for-mail From: Rich Grise <rich@example.net> Subject: Re: debounce state diagram FSM User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2007.05.03.19.26.38.712172@example.net> Newsgroups: comp.lang.vhdl,comp.arch.fpga,sci.electronics.design,comp.lang.verilog References: <1177871564.475673.53180@y80g2000hsf.googlegroups.com> <1178058355.292440.275760@l77g2000hsb.googlegroups.com> <ln647c5aqw.fsf@nuthaus.mib.org> <r2of33htqqttg5d9gmiqcnesfvo0kodcp0@4ax.com> <lnvefc3qst.fsf@nuthaus.mib.org> <pan.2007.05.02.23.31.21.488273@example.net> <59siaaF2k0rjfU1@mid.individual.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 20 Date: Thu, 03 May 2007 18:26:01 GMT NNTP-Posting-Host: 71.103.107.248 X-Complaints-To: abuse@verizon.net X-Trace: trnddc03 1178216761 71.103.107.248 (Thu, 03 May 2007 14:26:01 EDT) NNTP-Posting-Date: Thu, 03 May 2007 14:26:01 EDT Xref: prodigy.net comp.lang.vhdl:69944 comp.arch.fpga:130470 sci.electronics.design:802932 comp.lang.verilog:36043 X-Received-Date: Thu, 03 May 2007 14:26:02 EDT (nlpi060.nbdc.sbc.com) On Wed, 02 May 2007 22:40:10 +0000, Default User wrote: > Rich Grise wrote: > > >> Well, you could have removed comp.lang.c from your own followups, >> rather than perpetuating it. After all, you only want to bitch at the >> people in the other groups, right? >> >> And you do know how to set "followups-to", don't you? > > People keep saying this like it's some sort of magic. All that does > direct replies to THAT message to certain groups. It has jack to do > with the thread. Then change the "Newsgroups" field, like I've done with this post. Good Luck! RichArticle: 118794
In article <1178200419.714442.227530@l77g2000hsb.googlegroups.com>,
romi <weberrm@gmail.com> wrote:
>On May 2, 9:11 am, jhal...@TheWorld.com (Joseph H Allen) wrote:
>> // Concise priority arbiter
>> input [26:0] req; // Bit zero is highest priority
>> wire [26:0] gnt = req & -req; // Isolate least significant set bit
>> reg [26:0] prev; // Previous winner (saved from last cycle)
>> wire [26:0] req1 = req & ~((prev - 1) | prev); // Mask off previous winners
>> wire [26:0] gnt1 = req1 & -req1; // Select new winner
>> wire [26:0] winner = |gnt1 ? gnt1 : gnt; // Start from bit zero if none
>> // Save previous winner
>> always @(posedge clk) if (winner) prev <= winner;
>Since gnt1 implies that there was a req1, wouldn't it be better
>(faster) to use req1 in the winner selection?
>wire [26:0] winner = |req1 ? gnt1 : gnt; // Start from bit zero if
>none
Yes. Cool. :-)
Here are some other variations:
If the carry chain is really fast, get rid of the mux:
wire [53:0] req1 = { req, req & ~((prev - 1) | prev) };
wire [53:0] gnt1 = req1 & -req1;
wire [26:0] winner = gnt1[53:27] | gnt1[26:0];
Or use wrap-around carry, if you don't mind the combinatorial loop:
// Rotate previous winner one bit to the left. If no previous winner,
// pretend it was prev[26].
wire [26:0] prev1 = |prev ? { prev[25:0], prev[26] } : 27'd1;
// Wrap-around two's complement where the add 1 is just to the left of the
// previous winner instead of at bit 0.
wire [27:0] tmp = { 1'b0, ~req } + ({ 1'b0, prev1 } | { 27'b0, tmp[27] });
wire winner = req & tmp[26:0];
This is probably the fastest, but you need a synthesis tool which allows
combinatorial loops.
--
/* jhallen@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 118795Rich Grise wrote, On 03/05/07 19:36: > On Thu, 03 May 2007 00:13:04 +0100, Flash Gordon wrote: > >> Rich Grise wrote, On 02/05/07 23:41: >>> On Wed, 02 May 2007 08:02:40 +0100, Flash Gordon wrote: >>> >>>> Note I've not set followups this time because discussions about >>>> topicality *are* topical. >>> And you're still following up to the group that you want the crosspost >>> removed from. >>> >>> Are you C people all that lame? >>> >>> Here's a clue: Set your followups to: >>> comp.lang.vhdl,comp.arch.fpga,sci.electronics.design,comp.lang.verilog >>> for your whining and bellyaching - you might be surprised! >> That does sod all good because the off topic posts are not in response >> to it being redirected. > > So, change the "Newsgroups" field in the post that you're actually > posting, and to hell with the followups! > > See what I've done here? Look at my headers. See? No crosspost. That still does sod all good for the reason stated above. Restringing where MY post goes, or where follow ups to it go, does NOT affect where other messages go. > I also had to put that in by hand, since your "followups to" did, > in fact, default to everything but comp.lang.c - you simply have > to be smarter than your newsreader. No, it did not default, it was explicitly changed. I know EXACTLY how to use my news reader. > Sheesh! Try reading what was written. -- Flash GordonArticle: 118796
Rising_edge / Falling edge only matter if you're using non '0' / '1' values in your simulation... U -> '1' is not a rising edge with "rising_edge" but is a rising edge if you use 'EVENT. But U, H, X, L, etc... only exist in simulation, no such thing inside your FPGA, so assuming you setup your simulation to reflect reality there's no difference. On May 3, 12:17 pm, "Ben Jones" <ben.jo...@xilinx.com> wrote: > "Paul" <pauljbenn...@gmail.com> wrote in message > > news:1178203259.251061.292370@u30g2000hsc.googlegroups.com... > > > As far as I've heard/seen in large companies with regulated coding > > styles, > > the wait statement version of a DFF is considered to be sloppy for > > readability maintainability purposes. tick-event is considered a much > > cleaner way of coding a DFF. > > Well, the IEEE rising_edge and falling_edge functions are standard practice > and for good reason. The 'event syntax is beyond obsolete... > > -Ben-Article: 118797
Hi, Within our ASIC library, we have an I/O pad which has input pins allowing us to select whether a pullup, pulldown or none is enabled for this pad. This is very useful for GPIO. We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform, and we would like the same functionality. Is this possible ? Thanks, StevenArticle: 118798
Steven, http://direct.xilinx.com/bvdocs/userguides/ug331.pdf page 311. Yes. AustinArticle: 118799
moogyd@yahoo.co.uk schrieb: > Hi, > Within our ASIC library, we have an I/O pad which has input pins > allowing us to select whether a pullup, pulldown or none is enabled > for this pad. > This is very useful for GPIO. > > We are using an FPGA (Xilinx Spartan 3) as a delevlopment platform, > and we would like the same functionality. > > Is this possible ? > > Thanks, > > Steven only if you have device that has ICAP or then you route JTAG to GPIO and is not easy, need to modify the actual configuration Antti
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