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 Feb 4, 11:15=A0pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > -jg wrote: > > That's =A0a large market to isolate your devices from - one hopes the > > few picoseconds of speed that might have gained, turn out to be wrth > > it!! :) > > It more a question of die space. 3.3v tolerant IO is huge in 40/45nm. > In V6 they are trying to reach the high end of IO and LUT counts. On > the other hand with S6 the LUT counts are not that high and also the IO > count is lower than in V6 so they can waste space for the IO. Die Size, are you sure ? - My understanding is Oxide thickness is what primarily determines IO Voltage Specs. Die area (PAD IO area) more determines drive current. -jgArticle: 138026
Dear all, I'm working on a small project where I need a microblaze with external memory. It needs to be cheep so I guess SDRAM is the right choice? I don't need much memory. My next problem is how to connect it to the FPGA so microblaze can use it. I can't seem to find any detailed documentation. Maybe one of you have done the trick before and know where to find the information. Thanks in advance! Regards JanArticle: 138027
On Feb 4, 3:19=A0pm, "h.e." <h...@thisisnovalidaddress.net> wrote: > > This is my log with ise10.1 sp3 and libusb, maybe it helps to update the > firmware files being loaded? do you use the udev-rules suggested by > xilinx? ($XILINX/bin/lin64/xusbdfwu.rules) Thanks for the reply h.e. Yeah, I am using the udev, I think the installer sets that up during install. I double checked and it is all there. I also reinstalled ISE, and ISE+sp3. The origin ISE works just fine with the cable, I can program everything. It's the SP3 that broke something ... Best regards, rudiArticle: 138028
luudee schrieb: > On Feb 4, 3:19 pm, "h.e." <h...@thisisnovalidaddress.net> wrote: >> This is my log with ise10.1 sp3 and libusb, maybe it helps to update the >> firmware files being loaded? do you use the udev-rules suggested by >> xilinx? ($XILINX/bin/lin64/xusbdfwu.rules) > > > Thanks for the reply h.e. > > Yeah, I am using the udev, I think the installer sets that up > during install. I double checked and it is all there. > > I also reinstalled ISE, and ISE+sp3. The origin ISE works > just fine with the cable, I can program everything. It's the > SP3 that broke something ... > > Best regards, > rudi did you try the firmware version 1100? I had problems with older versions, too...Article: 138029
Long time passed since the last post but I wonder your opinions about this subject for today's technology. I am using a core2duo 1.8 GHz PC and for my design P&R takes 40 + minutes and want to buy a new PC powered by an AMD processor becasue of tis price but I can think some other configuration if it is worth, related to your opinions about : - dual core, quad core comparison - cache for the processor camparison Your suggestions will guide me. Regards, --enesArticle: 138030
I thought it would be a continuatiton for http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/50a3d3356726c68d/ Thanks in advance, --enesArticle: 138031
On Feb 3, 4:45 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 3 Feb 2009 13:21:25 -0800 (PST), jleslie48 wrote: > >Here's the simulation of the 16 character printout: > > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen... > > >everything looks to me ship-shape. > > >I'm gonna have to compare this simulation to a 15 character one. > > >anybody see anything? > > Yes. > > Jon, how do I put this politely.... > > (1) you're not listening; > (2) your debugging technique leaves something to be desired. > > I asked you whether you were leaving enough time for the serial > line to settle at its idle condition before the first character > goes out. You haven't answered, but the answer, very obviously, > ia "no, you're not". Your serial line idles for only a few > hundred nanoseconds before the first start bit goes out. > Depending on what the FPGA was doing during configuration, > that might or might not work downstream. It's hopeless. > > So your design is immediately broken. If it's broken, then > small differences between two forms of brokenness will mask > the real trouble. Insisting on fixing one minor issue when > so much else is so broken is just a recipe for wasting time. > > PLEASE, PLEASE fix the dreadful mess that is your data > generator. Only when you have something whose behaviour > is predictable and controllable can you hope to debug any > real problems. > > I sent you a private email suggesting ways you might > be able to get some useful support. It may have fallen > into your spamtrap, but whatever, I didn't get a response. > Several of us have seen that you are going at this in > a creative and generally intelligent, but badly flawed, > way; so you've had loads of suggestions that a less > thoughtful poster would not have received. For heaven's > sake take the higher-level advice too: SORT THE MESS OUT. > You've now futzed around for about three quite long days > and you still haven't got UART 101 working reliably. > Surely you're smart enough to see that the right solution > is to start again, properly? > > yours somewhat despairingly > -- > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Well, I cannot deny that I am floundering. I don't see your private email in my inbox or spam filter. I'm at jleslie48@yahoo.com or jon@jonathanleslie.com ~ I asked you whether you were leaving enough time for the serial ~ line to settle at its idle condition before the first character ~ goes out. You haven't answered, but the answer, very obviously, ~ ia "no, you're not". Your serial line idles for only a few ~ hundred nanoseconds before the first start bit goes out. ~ Depending on what the FPGA was doing during configuration, ~ that might or might not work downstream. It's hopeless. If I didn't answer then I apologize. The answer is I don't understand the question. It appears to me from this screen shot: http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap13_firstislast16.png that my serial line ( rs232_tx_data) idles for 955ns based on the whole system waiting for uart_reset_buffer. If that is not enough, then that was not made clear to me. I had some feelings that the issue lied somewhere with that, hence I supplied very careful screen caps of the waveforms, hoping someone would point out how to read them. I have never worked with waveforms/timing diagrams before. And while this might seem hopeless to you, I have no choice in the matter. I have no funding at this time to bring on additional personnel and quite frankly, prior to this discussion, I wouldn't of even been qualified to hire someone; one of my problems in the past. So to that level, this conversation has been productive for me at least. I am truly sorry my issues are so entry level, but we all must start somewhere. Every programming environment I've ever had to learn (and there have been many) has had by page 3 demonstrated the basic "hello world" program. I have been through many websites and textbooks and for this environment, it is very suspicious by its absence that the "hello world" program is missing. ~ You've now futzed around for about three quite long days ~ and you still haven't got UART 101 working reliably. ~ Surely you're smart enough to see that the right solution ~ is to start again, properly? Actually, I've been futzing around for 2 months and have "started again" 4 times already. Actually my associate has been futzing for almost 6, and this version is his interpretation of how to program. This version, warts and all, is the first is the first to at least send ANYTHING out. I think this messed up version is very close to working properly, and to abandon it now would be to miss out on understanding something important I am missing. Effecting a fix properly I still feel is important before adding another variable to the equation (new code with new issues) That's the way I debug, understand what you have first, try and fix, and then break it down to a streamlined scalable procedure.Article: 138032
On Tue, 3 Feb 2009 11:24:17 -0800 (PST), jleslie48 wrote: >> I make the message string: >> constant project_name_stg : string := "123456789a12345"; >> >> aka, 15 characters, all is well. >> I make it 16 characters: >> constant project_name_stg : string := "123456789a123456"; >> >> my output becomes: >> 23456789a1234561 >> >> were the 1 at the end is indeed the first character not the last. No conceivable way this could be correlated with the fact that your UART's FIFO buffer is 16 places deep, surely??? :-) -- 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: 138033
On Wed, 4 Feb 2009 05:42:01 -0800 (PST), jleslie48 wrote: > my serial line ( rs232_tx_data) idles for 955ns based on the >whole system waiting for >uart_reset_buffer. If that is not enough, then that was not made >clear to me. It's nowhere near enough to make me feel safe. Any real UART receiver - like the one in your PC - is quite likely to get messed-around by whatever happens in your FPGA during startup. So you MUST allow the line to idle for at least one CHARACTER time before sending anything; that way, the PC or whatever receiver will have a chance to sort itself out reliably before getting your data. A character time at 115kBd is, by my reckoning, around 90 microseconds - around a hundred times more than you currently allow. I'm not saying it will ALWAYS fail, but rather that here is a goofy variable in the debugging that might easily introduce nonsensical behaviour that would throw you off the scent of more important issues. >I had some feelings >that the issue lied somewhere with that, I am very sure that you have more than just one issue. > I have never worked with waveforms/timing diagrams before. yeah.... powerful, useful tool, but takes a bit of getting used to. >And while this might seem hopeless to you Did I say hopeless? Yes, but not about YOU - rather, about a piece of code, I think. > I have no choice in the matter. I have no >funding at this time to bring on additional personnel and quite >frankly, prior to this >discussion, I wouldn't of even been qualified to hire someone; one of >my problems in the past. Fair enough. Though I have to say that you're putting yourself in a fairly scary position. >I am truly sorry my issues are so entry level, > but we all must start somewhere. I know that very well. It seems to me that no beginner need ever apologize for asking interesting questions. However, one might reasonably accuse you of biting off too much at once..... > Every programming >environment I've ever had to learn (and there have been many) has had >by page 3 demonstrated the >basic "hello world" program. I have been through many websites and >textbooks and for this environment, >it is very suspicious by its absence that the "hello world" program is >missing. Hmmm.... I somewhat sympathise, but you might care to question why people continue to pay us non-trivial amounts of money for our very, very carefully designed training on exactly this kind of stuff. I am willing to bet a few beers that if you had spent this week on our class, rather than banging your head against a brick wall, you would be ready to move forward as soon as you got back to the office. Looking ahead a little: if you insist on regarding this as "programming" you are fairly sure to end up in the mire. Programming skills are good, useful, helpful; but hardware design requires a very clear *structural* vision of what you're trying to build, as well as a *procedural* one. >I think this messed up version is very close to working properly, and >to abandon it now would be to miss out on understanding something >important I am missing. OK. One last push. I'm on a couple of days' vacation so I will make a genuine effort to work out what you're doing wrong. Can't do very much more though, sorry. >That's the way I debug, understand what you have first, try and fix, >and then break it down to a streamlined scalable procedure. Yes, but when you have given yourself something very wrong indeed, the effort of understanding it may be a lot greater than the understanding justifies. Putting the same amount of effort into understanding a couple of well-written examples might pay much better dividends. -- 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: 138034
On Feb 4, 7:27=A0pm, "h.e." <h...@thisisnovalidaddress.net> wrote: > > did you try the firmware version 1100? I had problems with older > versions, too... How do I do that ? Sorry, I am not to familiar with the Xilinx USB stuff ... Thanks, rudiArticle: 138035
Jan wrote: > Dear all, > > I'm working on a small project where I need a microblaze with external > memory. > > It needs to be cheep so I guess SDRAM is the right choice? I don't > need much memory. > > My next problem is how to connect it to the FPGA so microblaze can use > it. I can't seem to find any detailed documentation. Maybe one of you > have done the trick before and know where to find the information. > > Thanks in advance! > > Regards > Jan Jan, Google. microblaze schematic site:xilinx.com HTH., Syms.Article: 138036
On Tue, 3 Feb 2009 15:12:41 +0000 (UTC), jhallen@TheWorld.com (Joseph H Allen) wrote: >I'm surprised that the Spartan-6 integrated memory controller does not support >DIMMs. Also surprised that there are no integrated memory controllers in >Virtex-6. > >Note the Virtex-6 Select-IO voltage range: only up to 2.5V! 2.5V is the >new 5V... Reading between the lines here... At a guess the V6 I/O blocks are fast enough to support DDR memory quite well without special support - and that way you have the flexibility to support any configuration you need (modulo SSO limitations; the tools will handle those) But the S6 would struggle without special support... which would explain why it has blocks the V6 doesn't. It is targetted at lower cost apps where you rarely need DIMMs. But at a guess you may be able to support DIMMs with some speed limitations; maybe you can tap into the memory controllers for all except the datapath. - BrianArticle: 138037
On Tue, 3 Feb 2009 18:14:23 +0100, "Jan Bruns" <testzugang_janbruns@arcor.de> wrote: > >"Joseph H Allen": >> Benjamin Couillard <benjamin.couillard@gmail.com> wrote: >>>On 3 fév, 10:12, jhal...@TheWorld.com (Joseph H Allen) wrote: >>>> I'm surprised that the Spartan-6 integrated memory controller does not support >>>> DIMMs. Also surprised that there are no integrated memory controllers in >>>> Virtex-6. >>>> >>>> Note the Virtex-6 Select-IO voltage range: only up to 2.5V! 2.5V is the >>>> new 5V... >>> >>>3.3V is the new 5V you might say > >> No, 3.3V was the old new 5V. The new new 5V is 2.5V. Altera Straitx-IV >> also does not support 3.3V I/O. > >Hm, ok, the old 5V-TTL logic devices pobably weren't compatible with >tube-level logic. Heh - maybe they were. If you wanted a high current PSU in those days, it tended to be 6.3V AC. Now if you multiply by sqrt(2), subtract a couple of diode drops, 10% for regulation, 5% for line tolerance, a volt for ripple, and enough for a linear regulator... you're about 5V. - BrianArticle: 138038
Hi All, I need help, and am willing to pay for it. If you can help me solve my problem, I will pay you. Name your price, and see if you can help me: Here is my problem: I am running Fedora Core 7, x86_86, kernel 2.6.28. I have libusb installed, and everything works fine with ISE 10.1. However, I am forced to upgrade to 10.1 sp3. And that's where everything breaks. I need for it to work "normally" with libusb, so I can use impact and chipscope. I can switch to 10.1 and it works, I go to sp3, and it is broken. Yeah, I do have XIL_IMPACT_USE_LIBUSB set. If you think you can help, please email me privately: rudolf.usselmann at gmail dot com Time is of essence ! Thanks ! rudi This is how impact fails: impact -batch etc/download.cmd [ ----- Deleted probing for parport ----- ] Using libusb. Connecting to cable (Usb Port - USB21). Checking cable driver. File version of /tools/Xilinx_10.1_x86_64/ISE_sp3/bin/lin64/ xusbdfwu.hex = 1030. File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1030. Using libusb. Max current requested during enumeration is 74 mA. Type = 0x0004. Cable Type = 3, Revision = 0. Setting cable speed to 6 MHz. Cable connection established. Firmware version = 1028. File version of /tools/Xilinx_10.1_x86_64/ISE_sp3/data/xusb_xlp.hex = 1303. Firmware hex file version = 1303. Downloading /tools/Xilinx_10.1_x86_64/ISE_sp3/data/xusb_xlp.hex. Downloaded firmware version = 1303. PLD file version = 0012h. PLD version = 0012h. bulk tranfer failed, endpoint=02. write count != nBytes(0), rc = 20000020. write cmd failed 20000020. control tranfer failed. write cmdbuffer failed 20000020. Error reading reference voltage level. Elapsed time = 3 sec. control tranfer failed. write cmdbuffer failed 20000020. Elapsed time = 3 sec.Article: 138039
On Feb 4, 5:05=A0pm, luudee <rudolf.usselm...@gmail.com> wrote: > Hi All, > > I need help, and am willing to pay for it. If you can > help me solve my problem, I will pay you. Name your > price, and see if you can help me: > > Here is my problem: > > I am running Fedora Core 7, x86_86, kernel 2.6.28. solution 1: get another cheap PC, install the required and working versions cable drivers there and connect over ethernet to your cable server PC fighting with impact is pointless to absurd. it sometimes works. thats all that can be said. that sametimes usually isnt then when you need it most. Antti PS good luck getting your paid answer..:) 11.1 is soon to be released, so you will again fight the linux drivers a winxp PC cableserver box is cheaper solutionArticle: 138040
On Feb 3, 8:33=A0pm, Eric Smith <e...@brouhaha.com> wrote: > Simon <goo...@gornall.net> writes: > > well, this is all very nice, but more importantly, when are they going > > to actually start delivering these things, and how much will they > > cost ? > > > I can't really believe they haven't *got* that information, so why the > > staged release of info ? > > When was the last time that a semiconductor vendor gave you such > information about a major new product release, and the information > actually proved to be reasonably accurate? Agreed, but then you take the price-estimate the vendor gave for the last series, get the 1-off, 100-off, 1000-off price (at launch) from your parts-source of choice, calculate the ratio and apply to the new vendor price as an approximation :) SimonArticle: 138041
On Feb 4, 6:15=A0pm, Simon <goo...@gornall.net> wrote: > On Feb 3, 8:33=A0pm, Eric Smith <e...@brouhaha.com> wrote: > > > Simon <goo...@gornall.net> writes: > > > well, this is all very nice, but more importantly, when are they goin= g > > > to actually start delivering these things, and how much will they > > > cost ? > > > > I can't really believe they haven't *got* that information, so why th= e > > > staged release of info ? > > > When was the last time that a semiconductor vendor gave you such > > information about a major new product release, and the information > > actually proved to be reasonably accurate? > > Agreed, but then you take the price-estimate the vendor gave for the > last series, get the 1-off, 100-off, 1000-off price (at launch) from > your parts-source of choice, calculate the ratio and apply to the new > vendor price as an approximation :) > > Simon Simon, simple math approx cheapest S3A qty one digikey price is 6.8$ from that i would derive 10k price to fall below 4$ (after price battle negotations...) if we assume some % price drop for S6 then we get what? 3$ So the price given by Xilinx (smallest S6 qty 10k =3D 3$) and publisched by Peter Clarke may actually be accurate. AnttiArticle: 138042
"Nathan Bialke" <nathan@bialke.com> wrote: > >The route I've considered, but not implemented, for something >approximating this is to use an Aurora-like protocol (with all K >characters being triplicated) with Reed Solomon encoding being done on >the data at the 8b/10b level (using 10 bit symbols). If you'd like >more detail, feel free to contact me. Hi Nathan, thanks for your reply. I'd like to go into more details about your suggestion because it sounds very interesting. I'm familiar with Reed-Solomon encoding. So tell me, what's the point in triplicating all K-characters? Do you apply the RS on the 10 bit symbols, i.e. after the phy coding layer? Regards, SaulArticle: 138043
On Feb 4, 11:13=A0pm, Antti <Antti.Luk...@googlemail.com> wrote: > > solution 1: > > get another cheap PC, install the required and working versions cable > drivers > there and connect over ethernet to your cable server PC > > fighting with impact is pointless to absurd. it sometimes works. > thats all that can be said. > > that sametimes usually isnt then when you need it most. > > Antti > PS good luck getting your paid answer..:) > 11.1 is soon to be released, so you will again fight > the linux drivers > > a winxp PC cableserver box is cheaper solution Hi Antti, yes, I have been thinking of what you have suggested as a "last resort". I figure give it a try and see if there is somebody out there who might know how to fix this really annoying problem ... Regards, rudiArticle: 138044
Hi with less delay than last month http://groups.google.com/group/antti-brain/files but probably even less polished :( well with monthly frequency, it has to be monthly released.. so it is out. i have received very little feedback so well. the little, well i appreciate it :) ah, there is also picture of 0.5mm BGA soldered on PCB made without any special technologies, 2 layer no microvia no super small track/space AnttiArticle: 138045
We have 5 Xilinx JTAG Cables on the same server working fine in our lab (with iMpact and ChipScope). From your error log it appears to be a problem with firmware versions. I also get the reference voltage error when the board isn't on or the JTAG isn't connected to the board. I personally have avoided Xilinx's drivers and have been using: http://www.rmdir.de/~michael/xilinx/ We have both Version 1 and 2 USB JTAG cables along with our own custom FTDI JTAG working with these drivers. I would suggest taking a look at Michael's driver. I wouldn't recommend Windows, because I cannot, in good conscience, ever recommend Windows. - Andy From rgaddi@technologyhighland.com Wed Feb 04 10:57:12 2009 Path: flpi142.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.lmi.net!news.lmi.net.POSTED!not-for-mail NNTP-Posting-Date: Wed, 04 Feb 2009 12:57:08 -0600 Date: Wed, 4 Feb 2009 10:57:12 -0800 From: Rob Gaddi <rgaddi@technologyhighland.com> Newsgroups: comp.arch.fpga Subject: Re: Core interface protocol Message-Id: <20090204105712.c659a0c8.rgaddi@technologyhighland.com> References: <58397ef9-070d-4449-b218-b192cb7af61b@t39g2000prh.googlegroups.com> Organization: Highland Technology, Inc. X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 32 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 66.117.134.49 X-Trace: sv3-B4xY16J4CLdjhPAMb7TGdJzb2i3KEVjVyqDgxOAjmV3pEruOjSlNfGf0w1BxvL1fgB8vUsz4LRUTY3O!N9s9595alT7J/hqt1Gn9ynyMBUsyQC+eCRdsyR9skFLzi0OYD6Bqrc7hEPto4EH5RvyaAVxgxTJL!41TufL67N3t4UeCvT7Q= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Xref: prodigy.net comp.arch.fpga:151165 X-Received-Date: Wed, 04 Feb 2009 13:57:10 EST (flpi142.ffdc.sbc.com) On Tue, 3 Feb 2009 22:33:13 -0800 (PST) Manny <mloulah@hotmail.com> wrote: > Hi, > > In trying to conform to good design practices, I have been doubting > lately my old ways. Until now, I've interfaced most of my cores to the > external system using standard 2/4-phase asynchronous handshake > protocols. Was wondering how good of a practice is this and whether > there is a definitive handbook out there in the literature that > tackles these issues. Don't want to sink into SoC bussing literature > with overly complicated arbitration since most of the designs I work > on are of the simple and tightly-coupled sort. > > Would appreciate any pointers on this. > > Regards, > Manny The last time I found myself trying to hook together just a few too many cores to go with my usual ad hoc interfaces, I ultimately wound up going over to a slightly stripped version of the WISHBONE SoC bus. Once you collapse the STB and CYC signals down to the same signal (which is the case for any single-master system that doesn't support bursting), what's left is really just a naming convention for the minimal set of signals you'd need to run. STB is your request, ACK is your acknowledge, and everything happens on the rising edge of the system clock. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 138046
On Feb 4, 10:15=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Nice to know I'm not the only curmudgeonly cynic out there :-) > > You're probably right. =A0Pessimists are rarely disappointed. "Been there, done that" :-) -- SvennArticle: 138047
On Feb 4, 8:42 am, jleslie48 <j...@jonathanleslie.com> wrote: > If I didn't answer then I apologize. The answer is I don't understand > the question. It appears to me from this screen shot: > > http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen... > > that my serial line ( rs232_tx_data) idles for 955ns based on the > whole system waiting for > uart_reset_buffer. If that is not enough, then that was not made > clear to me. I had some feelings > that the issue lied somewhere with that, hence I supplied very careful > screen caps of the waveforms, > hoping someone would point out how to read them. I have never worked > with waveforms/timing > diagrams before. Let me jump back into the discussion here. You seem to be getting frustrated with the slowness of the learning curve. Personally, I found HDLs to be hard to learn, but I think this is made worse when you are very used to designing software (as I have said before). So just take a deep breath and accept this fact. Many have dealt with this before and lived through it. In fact, maybe there is something good that can come of this. At this point there are tons of good HDL books out there, but I have not seen one specifically written for people with strong software backgrounds. Maybe we can work on a book together. You can be the guinea pig! ;^) I'm not totally clear on the current state of the discussion and some of this seems to be focusing on details that may or may not be important at this point. Timing diagrams are very simple. They are just graphs of signal values as a function of time. I am sure you get that, but you are just not accustomed to debugging with them. The main reason for using them to debug hardware is because using the alternative, code breakpoints and stepping, is rather tedious in HDL since the information is presented serially as it happens. A waveform display gives you a lot of information in parallel with essentially random access as you view it and figure out what is important or what is working and what isn't. I am not sure what is currently working and what isn't in your design. I will say that I think I have read that you are testing on hardware and something there is not working, I guess the first character is not being received by the other UART? Is that UART also in the FPGA or are you testing with a PC? Before you worry about testing hardware, I recommend that you run the simulation to show the circuit is working there. It is a hundred times easier to see what is happening in simulation than in a test fixture. Given that, I can't see anything in your simulation capture that shows anything wrong. It appears that sending data to the TX FIFO is working. The data sequence seems to be F23456789A123456 which is 16 chars, filling the FIFO as shown by the tx_buffer_full flag going high. After the first char is written to the FIFO I see an enable pulse on uart_en_16_x_baud and one clock later I see the rs232_tx_data go low. This all seems to be working as expected. I assume the baud enable is 16x the actual bit rate, so the simulation time is not long enough to watch the actual data emerge. Have you checked this to see that the simulation is transmitting the data correctly? If the data is being received by the FPGA UART, are all 16 chars received correctly? I am assuming that all of the above is true that the simulation shows things working correctly and that your only problem shows when you test on hardware. That would make sense given Jonathan's suggestion that you delay the start of your data transmission so that the receiving UART can clear out any garbage from the startup sequence. The startup delay may not be needed in simulation depending on the details of the startup sequence. This is one of the places where simulation can differ from the real world. In the real world there are often uncontrolled variables such as arbitrary delays, that are difficult to reproduce in simulation. Do I understand the current situation? > And while this might seem hopeless to you, I have no choice in the > matter. I have no > funding at this time to bring on additional personnel and quite > frankly, prior to this > discussion, I wouldn't of even been qualified to hire someone; one of > my problems in > the past. So to that level, this conversation has been productive for > me at least. The funding may be an issue. Even if you don't have funds to bring a consultant on board, you should get some training in this rather than try to tough it out yourself. I am sure you will eventually get it done, but it will be a much more expensive process and take a lot more time. > I am truly sorry my issues are so entry level, but we all must start > somewhere. Every programming > environment I've ever had to learn (and there have been many) has had > by page 3 demonstrated the > basic "hello world" program. I have been through many websites and > textbooks and for this environment, > it is very suspicious by its absence that the "hello world" program is > missing. Don't sweat your inexperience. Every one of us dealt with the same problems starting out. Usually the "hello world" program equivalent is the "traffic light state machine" when designing HDLs. Remember, this is *not* a programming language, it is a hardware *description* language. When used for synthesis, you really need to get used to the idea that you are NOT writing a program, you are describing hardware to be synthesized. Of course that is easy for me to say. I started out playing with JK FFs wired together on perf board powered by a 6 volt lantern battery. :^) Had 8080 CPU chips not been over $100 at the time, I might be a total software junkie now instead. Still, although your UART project may be a bit advanced for a beginner, it is not absurd and I expect you will be able to complete this shortly. If you find the UART is too frustrating, you might want to drop back to the traffic light program. > ~ You've now futzed around for about three quite long days > ~ and you still haven't got UART 101 working reliably. > ~ Surely you're smart enough to see that the right solution > ~ is to start again, properly? > > Actually, I've been futzing around for 2 months and have "started > again" > 4 times already. Actually my associate has been futzing for almost > 6, > and this version is his interpretation of how to program. This > version, > warts and all, is the first is the first to at least send ANYTHING > out. I think the above is an important data point. 2 months and 4 trials should be a sign that this method is not working well. The fact that someone has been trying this stuff for 6 months shows that you likely will not be ready to tackle a project for over a year! > I think this messed up version is very close to working properly, and > to abandon it now would be to miss out on understanding something > important I am missing. Effecting a fix properly I still feel is > important > before adding another variable to the equation (new code with new > issues) I don't want to sound like I am beating on you, but I think there are problems of approach and expectations that are much bigger than the technical issues. My first HDL project happened because I took a training class for Orcad schematic software that I was going to use for an FPGA design (HDL was not so universally used at that time). The last day of training taught VHDL. I was so impressed with the potential that I recommended that we use it on the project instead of schematics. As it turns out my greenness allowed me to miss the fact that the Orcad HDL tools blew big chunks. After spending a month or maybe two working with the Orcad synthesis tool I realized that it was never going to work and we bought the Xilinx tool (a third party tool bundled with the Xilinx back end). That worked much better. Looking back on my coding style, I realize that much of that code would likely not pass muster by my current standards. For example, I was using '-' as a don't care condition. I now know that this is not a good idea as it is not universally supported. I won't even think about the style I used back then... actually some of my style from that first project has served me well, but you get the idea. Your first project will likely not be anything that you are proud of a year later. > That's the way I debug, understand what you have first, try and fix, > and then break it down to a streamlined scalable procedure. That is fine for debugging, but you are primarily in a learning mode. That works much better when you take bite sized pieces and learn a bit at a time rather than to try to get a much more complex effort done that involves learning on many different levels. I think that when you complete the "hello world" example, you will still have a long way to go before you are ready to try a project. The fact that waveform displays are still new and alien to you is a *very* good indicator that you are still in the elementary school of HDL design. The more I think about it, the more I like the idea of writing a book. I don't currently have any design work, maybe I should take that on as a project. RickArticle: 138048
On Feb 4, 1:32=A0am, Bob Smith <use...@linuxtoys.org> wrote: > Hi, > > I would like to use a Spartan 3 100K FPGA to implement 16 > serial ports. =A0The ports will be fairly simple: 1200 to > 115200 baud, Tx, Rx, and two flow control lines per port. > > I already have a working serial port and could make sixteen > instances of it. =A0This would chew up a lot of the FPGA. > > Is there a better way to build sixteen serial ports? > > Would it make sense to build one serial port and try to > time division multiplex it to the sixteen sets of inputs, > perhaps keeping all state information in RAM? =A0Is this a > feasible or reasonable approach? When you say 16 serial ports will chew up a lot of the FPGA, have you measured the size of a simple UART? If you need a complex UART with FIFOs and handshake controls, I doubt that you will be able to save much by somehow combining them. But if you can use a simple UART with just data in each direction and just a holding register, I suspect even 16 of these will not be a big design. If it is, you can build a state machine that uses the LUTs as distributed RAM to emulate 16 registers and end up with a pretty optimized design. I just think this will be more work than it is worth. A simple UART should be on the order of 50 LUTs (I'm estimating here) so even x16 that would only be 800 of almost 2000 LUTs... maybe that *is* a lot. A sized optimized N duplicated UART might be an interesting design. RickArticle: 138049
On Feb 4, 9:09=A0pm, rickman <gnu...@gmail.com> wrote: > On Feb 4, 8:42 am, jleslie48 <j...@jonathanleslie.com> wrote: > [snip] > The more I think about it, the more I like the idea of writing a > book. =A0I don't currently have any design work, maybe I should take > that on as a project. > > Rick to OP: general rule for UART design after power on, and full system init that is UART mode setup, etc uart hardware init complete make sleep( 1 second); just wait 1 second before sending anything out the uart. i have also troubleshooted FPGA system that failed to send data on uart TX, well they actually worked, but during powerup the TX maybe active, those forcing BREAK condition, and only heaven know how much recovery after that may be required before PC will accept UART data. it is possible that FPGA sends 100 chars, and PC receives say 8 if the break was removed to quickly and the uart didnt sync properly at PC side. the problem is hardly ever there where you look first :) to Rick: i also have/have had plans of writing various stuff(books) one of them would be titled "art of abstract problem solving".. missing uart print is one good example where this art shoud be applied :) 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