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 Mar 26, 8:43=A0pm, Alan Fitch <alan.fi...@spamtrap.com> wrote: > there are two (or two and a half?) answers > > 1. You do it manually. > 2. You pay a lot of money for a behavioural synthesis tool > 2.5 Certain RTL synthesis tools do sometimes understand a so-called > implicit state machine style, Thanks Alan. That makes it completely clear. It's an epiphanhy moment in hardware design for me. I get how the flow of information through the hardware works. And how difficult this is! It's all just lots of work to manual labour! DaveArticle: 146701
On 26/03/2010 10:34, da_wils@hotmail.com wrote: > Hi, > > I'm making a uart that will run at the standard baud rates and have a > bit of a query, > My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock > then derive all the baud clocks from it,,eg, > -- 50mhz/ 1843200 = 27.1267 > -- 13 bit acc = 4096 msb > -- divided by 151 > -- 4096/151 = 27.1258 -- close enough > -- gives 1.843262MHz clock > > this is fine for TX but when it comes to RX where the accepted sample > clk is 16x the baud rate I hit a few problems. I wanted to sample the > incoming bit period at 4 16x clocks, 8 16x clocks and 12 16x clock and Sample at clocks 7, 8 and 9 and take a majority vote. That's how (almost) all standard uarts handle receive sampling. Spreading it out by using clock 4, 8 and 12 gives you no better noise immunity and makes your uart far more sensitive to baud rate accuracy. Start bit edges need to be sampled at every 16x clock, of course. > use the theory that if two samples match then RX bit is good, It's > this generation of a 16x clock that is causing me problems, not easy > to create for all baud rates. At the moment I'm sampling the RX at > 50MHz and taking samples at three points, this scheme works but seems > a bit inefficient due to having to have a bank of constants with the > the various count values for different baud rates. > > Has anyone come across this problem ? All standard baud rates are integer fractions of 115200. So when you have your 1.84 MHz clock, you simply divide it by the baud divisor to get your 16x clock (i.e., divide by 1 for 16 x 115200, by 6 for 16 x 19200, etc.). If it's easier for your hardware, use a faster clock that 1.84 MHz as the base - you can get away with 1% error (theoretically up to 5% total) in the baud clock.Article: 146702
On 26/03/2010 10:38, weldat wrote: > Hi every body; > i am working on xilinx EDK with MicroBlaze soft core processor. i am using > Virtex 5 ML506 platform studio and my EDK is EDK 9.2 > on this processor i am downloading C code for Elliptic curve diffie-hellman > key exchange and it is done but result is not displayed on the > hyperterminal so is there any body who can help me how to fix my problem? > but the connetion of the RS232_uart is working properly i have checked it > with simple C code. the baud rate is all ok > thank you in advance. > kind regards > weldat I have no idea about your system, but hyperterminal is notoriously unreliable and entirely unsuitable to embedded development. Try a decent terminal emulator first to eliminate that source of problem. Many people (including me) like Tera Term Pro, but there are hundreds of alternatives.Article: 146703
On Mar 26, 11:18=A0am, "Maurice Branson" <trauben...@arcor.de> wrote: > "Andrew Jackson" <a...@nospam.com> wrotenews:X_adnaUfiO556jHWnZ2dnUVZ8l2d= nZ2d@eclipse.net.uk... > > > ways, you would be better doing a USB2.0 device and sticking on a suita= ble > > USB PHY for the physical interface. =A0There aren't many USB 3.0 hosts > > around yet against which you could test your device either: lots > > Thanks, Andrew! > > Sounds resonable to me. So if I start with 2.0 is there a compatibility t= hat > I may "expand" my design to a 3.0 core or is it totally different? I lear= ned > from what I've read here and in the www that I need at least a separate P= HY > because that is something that I cannot to in the FPGA fabric. Are there = any > USB 3.0 PHYs already available? Found nothing. :-( > > KR Maurica 3.0 core is basically separate from 2.0 on almost every layer, if you have a usb 3.0 device it tries to connect using super speed and if that is not available on the other side, the 3.0 core shuts down and 2.0/1.1 core starts its operation. The PHY is not publicly available, because there is no market for it, right now only big companies working on usb 3.0 appliances (like WD, Samsung, Intel, ...) have it available.Article: 146704
Hi everyone, I'm implenting a design on a Virtex4 that has to follow the communication of a processor with the ddr memory that is on the board. The board that I'm using is an Avnet ADS-XLX-V4LX-DEV160. The bridge that link the processor with the memory at the end has a Xilinx component IOBUF to transmit and receive data and strobe (bidirectional). It looks that all the signal sent to the memory are right, but the problem is that the data signals received from the memory are always to 1 like if the memory is turned off. I checked the file .ucf for the connection and it looks right. Does someone know what could be the problem? Thanks Pierpaolo --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146705
On Mar 26, 1:30=A0pm, wojtek <wojtekpowiertow...@gmail.com> wrote: > On Mar 26, 11:18=A0am, "Maurice Branson" <trauben...@arcor.de> wrote: > > > "Andrew Jackson" <a...@nospam.com> wrotenews:X_adnaUfiO556jHWnZ2dnUVZ8l= 2dnZ2d@eclipse.net.uk... > > > > ways, you would be better doing a USB2.0 device and sticking on a sui= table > > > USB PHY for the physical interface. =A0There aren't many USB 3.0 host= s > > > around yet against which you could test your device either: lots > > > Thanks, Andrew! > > > Sounds resonable to me. So if I start with 2.0 is there a compatibility= that > > I may "expand" my design to a 3.0 core or is it totally different? I le= arned > > from what I've read here and in the www that I need at least a separate= PHY > > because that is something that I cannot to in the FPGA fabric. Are ther= e any > > USB 3.0 PHYs already available? Found nothing. :-( > > > KR Maurica > > 3.0 core is basically separate from 2.0 on almost every layer, if you > have a usb 3.0 device it tries to connect using super speed and if > that is not available on the other side, the 3.0 core shuts down and > 2.0/1.1 core starts its operation. The PHY is not publicly available, > because there is no market for it, right now only big companies > working on usb 3.0 appliances (like WD, Samsung, Intel, ...) have it > available. well, USB 3.0 is the first one that needs NO PHY as the MGT's in some newer FPGA's are USB 3.0 capable directly just wire MGT to usb 3.0 superspeed pins, and that about it AnttiArticle: 146706
On Mar 26, 5:34=A0am, da_w...@hotmail.com wrote: > Hi, > > I'm making a uart that will run at the standard baud rates and have a > bit of a query, > My board has a 50Mhz clk so I've used this to create a 1.8432Mhz clock > then derive all the baud clocks from it,,eg, > -- 50mhz/ 1843200 =3D 27.1267 > -- 13 bit acc =3D 4096 msb > -- divided by 151 > -- 4096/151 =3D =A027.1258 -- close enough > -- gives 1.843262MHz clock > > this is fine for TX but when it comes to RX where the accepted sample > clk is 16x the baud rate I hit a few problems. I wanted to sample the > incoming bit period at 4 16x clocks, 8 16x clocks and 12 16x clock and > use the theory that if two samples match then RX bit is good, It's > this generation of a 16x clock that is causing me problems, not easy > to create for all baud rates. At the moment I'm sampling the RX at > 50MHz and taking samples at three points, this scheme works but seems > a bit inefficient due to having to have a bank of constants with the > the various count values for different baud rates. > > Has anyone come across this problem ? Why not just run everything from the 50MHz clock directly? Using simple counters you can get as precise as you need for the UART application whether for your 16x clock at high baud rates or 1x at the lowest. You could even go for more precision at the cost of 20ns of clock jitter by using an accumulator as the divider rather than a counter.Article: 146707
On Mar 26, 5:38=A0am, "weldat" <gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Hi every body; > i am working on xilinx EDK with MicroBlaze soft core processor. i am usin= g > Virtex 5 ML506 platform studio and my EDK is EDK 9.2 > on this processor i am downloading C code for Elliptic curve diffie-hellm= an > key exchange and it is done but result is not displayed on the > hyperterminal so is there any body who can help me how to fix my problem? > but the connetion of the RS232_uart is working properly i have checked it > with simple C code. the baud rate is all ok > thank you in advance. > kind regards > weldat =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I saw a thread recently where hyperterminal was dropping data. It turned out hyperterminal wasn't treating the hex '00 values as data despite the attempts to make the transfer "binary" and gummed up the whole effort. If you're using raw data, perhaps you should change to where you transfer ASCII hex characters instead. In pseudocode: 4'h0 =3D=3D 8'c"0", 4'hf =3D=3D 8'c"F"Article: 146708
On Mar 26, 1:58=A0pm, Antti <antti.luk...@googlemail.com> wrote: > well, USB 3.0 is the first one that needs NO PHY > > as the MGT's in some newer FPGA's are USB 3.0 capable directly > just wire MGT to usb 3.0 superspeed pins, and that about it > > Antti That is the first time i hear abou MGT being compatible with USB 3.0 PHY, but I haven't doing anything in USB 3.0 topic for almost a year. I must say I find it hard to believe thought, because USB 3.0 besides translating digital signal to differential analog signal also transmits USB 3.0 specific LFPS (low frequency pulse signaling) and from what I learned the USB 3.0 PHY was supposed to take care of that (just like latest PCI express PHY, which has similar LFPS technology). I believe the MGT doesn't support that. But as I've said I hadn't even researched it for some time, so I might be wrong.Article: 146709
Thanks for all your answers, I'll generate a16x clock and give it a try otherwise I don't see any problem oversampling using the 50MHz clock my 1.84Mhz clock uses the accumulator method with a 20ns jitter, seems to run ok, DaveArticle: 146710
On 25 Mrz., 17:18, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > Thinking about it further, I suppose I didn't mean stay exactly the > same. I did expect differences, and I guess I confirm with you all that > what I am seeing is normal. I have typically less than 5% fluctuations > between runs. > > Thanks for all your input. It gives me a bit to think about. The problem is, that your frequency might be very fast with 5 stage ring oscillator. Expect the clock frequency to equal the gate delay of not more than 5 gates :). Your counter will experience very fast clock cycles which lead to results with no meaning if your counter is not designed to work with that fast clock frequency. Second problem, how do you avoid having more than one level transaction in the oscillation ring? (e.g. 01010). bye ThomasArticle: 146711
On Mar 25, 5:26=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > > In North America, that is Avnet (as you have noted). =A0I suggest you > > call them on the phone and request quotes and delivery. > > Why shouldn't Xilinx tell us when parts are available. > They are the mfg. They probably have a better idea. > Even an approximation would be better than nothing. With Xilinx, I just look at the list of parts that have errata so far. This will give you a good idea of what parts will go into production first. ahArticle: 146712
On 03/25/2010 11:24 PM, David Wiltshire wrote: > On Mar 26, 6:06 am, Jason Thibodeau<jason.p.thibod...@gmail.com> > wrote: >> Is it possible to get a detailed report out of XST, listing the gates it >> has optimized out of a design? XST is removing some gates that I >> specifically put into a design, and I want to prevent this. I can use >> the XST constraints file, but I'd like to see exactly what it is doing. >> >> Googling hasn't turned up much, yet. >> >> Thanks >> -- >> Jason Thibodeau > > Not that I'm experienced but whenever I've seen a similar question > (missing logic) it's been optomised out because you haven't connected > the output to anything. Try connecting it to a pin out (even if > that's not where you want it eventually) and see if it turns up. > > Dave Yes, I ran across that and I connected the output. Only the last gate in the design is being synthesized. All the other gates, which connect to it, are being optimized out. -- Jason ThibodeauArticle: 146713
On 03/26/2010 11:15 AM, Thomas Stanka wrote: > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com> > wrote: >> Thinking about it further, I suppose I didn't mean stay exactly the >> same. I did expect differences, and I guess I confirm with you all that >> what I am seeing is normal. I have typically less than 5% fluctuations >> between runs. >> >> Thanks for all your input. It gives me a bit to think about. > > The problem is, that your frequency might be very fast with 5 stage > ring oscillator. Expect the clock frequency to equal the gate delay of > not more than 5 gates :). Your counter will experience very fast clock > cycles which lead to results with no meaning if your counter is not > designed to work with that fast clock frequency. > Second problem, how do you avoid having more than one level > transaction in the oscillation ring? > (e.g. 01010). > > bye Thomas > > Yes, I was discussing that with a colleague yesterday. The oscillator may be too fast for the counter to read it accurately. I'm using a the output oscillator signal to clock the counter, however the oscillation frequency may be too fast to meet the required set-up and hold time for the counter. I'm investigating that now. -- Jason ThibodeauArticle: 146714
"weldat" <gwelekiros@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: >Hi every body; >i am working on xilinx EDK with MicroBlaze soft core processor. i am using >Virtex 5 ML506 platform studio and my EDK is EDK 9.2 >on this processor i am downloading C code for Elliptic curve diffie-hellman >key exchange and it is done but result is not displayed on the >hyperterminal so is there any body who can help me how to fix my problem? >but the connetion of the RS232_uart is working properly i have checked it >with simple C code. the baud rate is all ok >thank you in advance. Short pins 2 & 3 on the plug to see if characters get echoed when typing. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146715
On Mar 26, 6:04=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > On 03/26/2010 11:15 AM, Thomas Stanka wrote: > > > > > > > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com> > > wrote: > >> Thinking about it further, I suppose I didn't mean stay exactly the > >> same. I did expect differences, and I guess I confirm with you all tha= t > >> what I am seeing is normal. I have typically less than 5% fluctuations > >> between runs. > > >> Thanks for all your input. It gives me a bit to think about. > > > The problem is, that your frequency might be very fast with 5 stage > > ring oscillator. Expect the clock frequency to equal the gate delay of > > not more than 5 gates :). Your counter will experience very fast clock > > cycles which lead to results with no meaning if your counter is not > > designed to work with that fast clock frequency. > > Second problem, how do you avoid having more than one level > > transaction in the oscillation ring? > > (e.g. 01010). > > > bye Thomas > > Yes, I was discussing that with a colleague yesterday. The oscillator > may be too fast for the counter to read it accurately. I'm using a the > output oscillator signal to clock the counter, however the oscillation > frequency may be too fast to meet the required set-up and hold time for > the counter. I'm investigating that now. > > -- > Jason Thibodeau it depend the architecture and routing its a good idea to run the ring oscillator to single flip flop that divides by 2 the output of that FF is more likely in the range that is ok to use in the same FPGA as "system clock" the plain ring oscillator may run too fast AnttiArticle: 146716
Jason Thibodeau <jason.p.thibodeau@gmail.com> wrote: > On 03/26/2010 11:15 AM, Thomas Stanka wrote: (snip) >> The problem is, that your frequency might be very fast with 5 stage >> ring oscillator. Expect the clock frequency to equal the gate delay of >> not more than 5 gates :). Your counter will experience very fast clock >> cycles which lead to results with no meaning if your counter is not >> designed to work with that fast clock frequency. With routing delay being one of the slower parts of newer FPGAs that doesn't seem so likely, unless... >> Second problem, how do you avoid having more than one level >> transaction in the oscillation ring? >> (e.g. 01010). That would speed up the count. If you can route to an output pin without changing the oscillator too much, then look at it on a scope. > Yes, I was discussing that with a colleague yesterday. The oscillator > may be too fast for the counter to read it accurately. I'm using a the > output oscillator signal to clock the counter, however the oscillation > frequency may be too fast to meet the required set-up and hold time for > the counter. I'm investigating that now. It would be best to use the built-in clock distribution. Otherwise, a ripple counter (from the 7493 days) should avoid clock skew problems. Another idea is to use a gray code counter. I can see cases where clock skew on a very fast clock would give strange results, but the OP never actually posted any counts. To use a ripple counter, one would have to gate the clock, and stop it long enough to read out the result. If you use one input to all five LUTs as a gate, that might make it more likely to start in the desired state. (And also might avoid the optimizer removing inverters from the loops.) -- glenArticle: 146717
On Mar 26, 12:04=A0pm, Jason Thibodeau <jason.p.thibod...@gmail.com> wrote: > On 03/26/2010 11:15 AM, Thomas Stanka wrote: > > > > > > > On 25 Mrz., 17:18, Jason Thibodeau<jason.p.thibod...@gmail.com> > > wrote: > >> Thinking about it further, I suppose I didn't mean stay exactly the > >> same. I did expect differences, and I guess I confirm with you all tha= t > >> what I am seeing is normal. I have typically less than 5% fluctuations > >> between runs. > > >> Thanks for all your input. It gives me a bit to think about. > > > The problem is, that your frequency might be very fast with 5 stage > > ring oscillator. Expect the clock frequency to equal the gate delay of > > not more than 5 gates :). Your counter will experience very fast clock > > cycles which lead to results with no meaning if your counter is not > > designed to work with that fast clock frequency. > > Second problem, how do you avoid having more than one level > > transaction in the oscillation ring? > > (e.g. 01010). > > > bye Thomas > > Yes, I was discussing that with a colleague yesterday. The oscillator > may be too fast for the counter to read it accurately. I'm using a the > output oscillator signal to clock the counter, however the oscillation > frequency may be too fast to meet the required set-up and hold time for > the counter. I'm investigating that now. > > -- > Jason Thibodeau- Hide quoted text - > > - Show quoted text - The rule of thumb (at least for brand X FPGAs) is 500ps of propagation delay per LUT. Assuming your ring buffer is actually getting generated as you expect (and synthesis isn't reducing it to a single LUT not gate), not including routing, I'd guess you're looking at ~400MHz as an upper bound. Depending on your FPGA, this may or may not be acceptable fundamentally in the fabric. Moreover, your counter has to run at least this fast. ChrisArticle: 146718
David Wiltshire <dw_56@hotmail.com> wrote: (snip) > Thanks Alan. That makes it completely clear. It's an epiphanhy > moment in hardware design for me. I get how the flow of information > through the hardware works. And how difficult this is! It's all just > lots of work to manual labour! I don't know that it is so much more difficult, but the thought processes are different. Some of use grew up in the days when TTL gates were popular and easy to buy and play around with. When digital clock that you bought in stores were mechanical, but you could build them from TTL (and maybe some MOS). When freshman lab courses had students build projects out of TTL gates. As I understand it, now freshman labs only do simulations, but never actually build anything! -- glenArticle: 146719
dave <da_wils@hotmail.com> wrote: > Thanks for all your answers, > I'll generate a16x clock and give it a try otherwise I don't see any > problem oversampling using the 50MHz clock > my 1.84Mhz clock uses the accumulator method with a 20ns jitter, seems > to run ok, I used to have an Epson MX-100 printer connected to a TRS-80 color computer through a serial interface. The serial interface option is based on the intel 8049, such that the UART is done in software. (I once thought about dumping the ROM, but never did.) The Color Computer also uses a software UART, directly timed by loops in 6809 code. One program I had didn't work so well, and I found out that the printer likes faster clocks, but for even slightly slower, it would fail. A small change to the timing loop in the 6809 code resolved the problems. A 1% timing error accumulates over 10 bits as 10% of the clock period. With the 6% due to the 16x clock, and the possible non 50% duty cycle input, you don't want to be too far off, but a few percent isn't so bad. (Leave some margin for the other end, too.) -- glenArticle: 146720
Aditi wrote: > Hi, > > I am planning to use a Spartan 6 FPGA (XC6SLX9) in my new design. > Could someone suggest a reprogrammable PROM to configure this device, > like the capacity of the Flash PROM needed ? Also, SST has a line of flash proms. I use their 1-mbit version on a smaller FPGA, but they have a 4 mb part, http://mouser.com/ProductDetail/Atmel/AT29LV040A-15TU/?qs=sGAEpiMZZMtI%252bQ06EiAoG1KfhKGNTAIqdwDuLxOe7u0%3d I use the so-8 package, but they have a smaller chip-scale version. JonArticle: 146721
Aditi wrote: > Hi, > > I am planning to use a Spartan 6 FPGA (XC6SLX9) in my new design. > Could someone suggest a reprogrammable PROM to configure this device, > like the capacity of the Flash PROM needed ? OOPS, wrong part. The part I'm using is the SST 25VF010A, the 4 Mbit part is the SST25VF040, they have a couple variants and package choices. These things are MUCH cheaper than some other makers, and have worked quite well in my application. I did have to write my own serial programming routine for them, but it wasn't too hard. JonArticle: 146722
> The second one is basically useless. > The reason is the estimate of a logic speed and how they are generated > in most efficient way > are the topics of HDL compilers and it becomes other people's > business, not a digital logic designer's business. Hi Weng, I do not know the book, but it is hard for me to not disagree with the statement, that a digital logic designer is not responsible for the speed of the circuit. Especially when you are talking about domino logic, etc. in your other posts, when I remember right ;-) Regards, ThomasArticle: 146723
On Thu, 25 Mar 2010 18:41:06 +0000 (UTC), glen herrmannsfeldt wrote: >> Why do we need power planes? Are we trying to keep the "reference >> rails" common between chips to a very high degree like we do with our >> ground planes? > >Some drivers can pull up almost as much as down. True, for sure. But in the olden days (and remember, I'm an olden-days person) ground, but never power, was used as a reference for inputs. Is that still true? My gut tells me that CMOS inputs need both power and ground to be well- behaved if they are to act sensibly. Does anyone know different? -- Jonathan BromleyArticle: 146724
On Mar 26, 3:26=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > >> Second problem, how do you avoid having more than one level > >> transaction in the oscillation ring? > >> (e.g. 01010). > > That would speed up the count. =A0If you can route to an output > pin without changing the oscillator too much, then look at it > on a scope. There's a strong possibility the I/O won't have the bandwidth to pass the full signal. A short back and forth for a small pulse might get lost in the I/O.
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