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
Michael Keith <mjkeith@gmx.de> writes:
> IIRC the main part of the book is about Tk, however - not
> astonishing, given the simplicity of Tcl.
I seem to remember that John Ousterhout's book was more focused on the
Tcl language than the Welch book:
http://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032133633X
However, that was 10+ years ago so things might have changed somewhat
in the later editions.
I think the most important discovery for programmers learning Tcl is
that it does not have syntax, it's only command [arg1 ... argn]. {},
[], "" are just methods for quoting. e.g. "if" is a command which have
two or three arguments. The first is evaluated and if it is zero it
will execute the second argument (if given), if non-zero it will
execute the first one:
% if 0 "puts yes" "puts no"
no
% if 1 "puts yes" "puts no"
yes
% expr 1==1
1
% expr 1==0
0
% set hhh world
world
% string equal "hello $hhh" {hello world}
1
% string equal "hello $hhh" {hello $hhh}
0
% puts "hello $hhh"
hello world
% puts {hello $hhh}
hello $hhh
You have to learn the quoting rules and then look upp all the
different commands on the net or in a book.
//Petter
--
.sig removed by request.
Article: 153276I use TCL/TK in a nutshell by Paul Raines and Jeff Tranter as a desktop reference. I like it, and it's available pretty cheaply second hand. Also the TCL website http://wiki.tcl.tk/ provides a good way of looking up commands etc. Best regards, SimonArticle: 153277
I too have the Brent Welch book (though not the latest edition), and I reckon that it was a good purchase... --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153278
Are there any simple practical [fpga internal] solutions to aviod internal "ringing" on slow (edged) clock inputs on fpga's, other than resampling and filtering in a different clock domain? (Using Altera Stratix III atm)Article: 153279
Morten Leikvoll <mleikvol@yahoo.nospam> wrote: > Are there any simple practical [fpga internal] solutions to aviod internal > "ringing" on slow (edged) clock inputs on fpga's, other than resampling and > filtering in a different clock domain? > (Using Altera Stratix III atm) Best to keep the slow edge out. You could connect the clock to a nearby output, with a resistor (of appropriate size) to the input, to supply a little positive feedback. (An additional small series resistor if the clock generator output is too low impedance.) Even better is to do it before it gets to the clock input. -- glenArticle: 153280
On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote: > Morten Leikvoll <mleikvol@yahoo.nospam> wrote: >> Are there any simple practical [fpga internal] solutions to aviod >> internal "ringing" on slow (edged) clock inputs on fpga's, other than >> resampling and filtering in a different clock domain? (Using Altera >> Stratix III atm) > > Best to keep the slow edge out. > > You could connect the clock to a nearby output, with a resistor (of > appropriate size) to the input, to supply a little positive feedback. > (An additional small series resistor if the clock generator output is > too low impedance.) > > Even better is to do it before it gets to the clock input. Yup. One little Schmitt trigger in an SOT-23 (or smaller) package, and suddenly your clock is clean (well, cleaner). Or have you already gotten the board laid out and built, and now you need a bandaid? -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153281
Hi, II'd like to know if there exists an open source implementation of Xilinx cable server, allowing to run it on a platform for which Xilinx does not provide binaries. Of course it is possible to implement it as e.g. remote parport device (as Xilinx tools support parport connected programmers on Linux platform), but this solution would probably suffer the performance penalty. Another solution would be to split the linux open source driver ( http://rmdir.de/~michael/xilinx/ ) into two parts communicating via TCP/IP, as I suggested in my post to comp.arch.embedded "Crazy idea - Embedded PC + USB debugging with QEMU - passing of only one USB interface to QEMU, or distributed libusb-driver" ( http://groups.google.com/group/comp.arch.embedded/browse_thread/thread/7e425d14fefb20fa/af9623faf7f48f66 ). Both however are suboptimal solutions. The most efficient would be simply to have functional replacement of cse_server running on remote embedded system connected to the debugged FPGA. Has anyone tried to do this? Does anybody know if the cse_server protocol is documented? -- TIA & Regards, WZabArticle: 153282
"Tim Wescott" <tim@seemywebsite.com> wrote in message news:WNydnTO0ir1Fp73SnZ2dnUVZ_jWdnZ2d@web-ster.com... > On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote: > >> Morten Leikvoll <mleikvol@yahoo.nospam> wrote: >>> Are there any simple practical [fpga internal] solutions to aviod >>> internal "ringing" on slow (edged) clock inputs on fpga's, other than >>> resampling and filtering in a different clock domain? (Using Altera >>> Stratix III atm) >> >> Best to keep the slow edge out. >> >> You could connect the clock to a nearby output, with a resistor (of >> appropriate size) to the input, to supply a little positive feedback. >> (An additional small series resistor if the clock generator output is >> too low impedance.) >> >> Even better is to do it before it gets to the clock input. > > Yup. One little Schmitt trigger in an SOT-23 (or smaller) package, and > suddenly your clock is clean (well, cleaner). > > Or have you already gotten the board laid out and built, and now you need > a bandaid? Im really just lazy.. This clock is so slow I can resample it (got a 100Mhz available for that), but I wrote and simulated it for direct clk (it's the SCL of a i2c bus, and to make the case even worse, its the SCL of a DVI DDC bus wich runs on long, often bad quality wires with SDA/SCL crosstalk). I was kinda hoping for some builtin schmitt trigger attribute that I could assign to it. I'll start on the resampling part right now ;p ThanksArticle: 153283
I've found the old post: http://www.fpgarelated.com/usenet/fpga/show/51158-1.php pointing to http://sourceforge.net/projects/xilprg/ I've not verified it yet with hardware, but after first look it seems to be a good point to start.Article: 153284
Hi, I am using xilinx spartan 3 xc3s4000 FPGA in my design interfaced with two gigabit phyters from National and I have xilinx xcf16p EEPROM on board to program the FPGA. When I program the FPGA using JTAG, everything works perfectly fine. I get the behavior that I expect it to give but when I generate the .mcs file from that .bit file and program my EEPROM, then let EEPROM program my FPGA on startup, my FPGA doesn't work. The DONE signal goes high, I can see the core detected in Chipscope pro, but my FPGA's funcitonality is weird and by weird I mean it doesn't behave as expected. I don't know why is this happening when my .bit file is working fine. My whole system collapses when I use EEPROM. Any ideas ? Regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153285
On Jan 26, 11:46=A0am, "salimbaba" <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: What about the JTAG pins? Are they pulled up/down? If they are floating, your system may behave erratically. However if you use Chipscope, then probably JTAG pins are driven correctly. What about the startup clock? What about reset? That's all I can imagine now. -- HTH & Regards, WZabArticle: 153286
Startup clock is CCLK, config clock is default (6). About the reset, It is defined pull down on an IO. Also, when I program the FPGA using EEPROM, and try to send packets through the phyters, I get very frequent disconnections, which are not there when I program it using JTAG. >On Jan 26, 11:46=A0am, "salimbaba" ><a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: > >What about the JTAG pins? Are they pulled up/down? If they are >floating, your system may behave erratically. >However if you use Chipscope, then probably JTAG pins are driven >correctly. > >What about the startup clock? >What about reset? >That's all I can imagine now. >-- >HTH & Regards, >WZab > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153287
On Thu, 26 Jan 2012 09:41:46 +0100, Morten Leikvoll wrote: > "Tim Wescott" <tim@seemywebsite.com> wrote in message > news:WNydnTO0ir1Fp73SnZ2dnUVZ_jWdnZ2d@web-ster.com... >> On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote: >> >>> Morten Leikvoll <mleikvol@yahoo.nospam> wrote: >>>> Are there any simple practical [fpga internal] solutions to aviod >>>> internal "ringing" on slow (edged) clock inputs on fpga's, other than >>>> resampling and filtering in a different clock domain? (Using Altera >>>> Stratix III atm) >>> >>> Best to keep the slow edge out. >>> >>> You could connect the clock to a nearby output, with a resistor (of >>> appropriate size) to the input, to supply a little positive feedback. >>> (An additional small series resistor if the clock generator output is >>> too low impedance.) >>> >>> Even better is to do it before it gets to the clock input. >> >> Yup. One little Schmitt trigger in an SOT-23 (or smaller) package, and >> suddenly your clock is clean (well, cleaner). >> >> Or have you already gotten the board laid out and built, and now you >> need a bandaid? > > Im really just lazy.. This clock is so slow I can resample it (got a > 100Mhz available for that), but I wrote and simulated it for direct clk > (it's the SCL of a i2c bus, and to make the case even worse, its the SCL > of a DVI DDC bus wich runs on long, often bad quality wires with SDA/SCL > crosstalk). I was kinda hoping for some builtin schmitt trigger > attribute that I could assign to it. > I'll start on the resampling part right now ;p If it's noisy you might want to do more than just resampling it. Resample, then make a filter that only transitions if the input has been at the new value for N consecutive FPGA clocks (with N chosen empirically to pound down the known noise, or maybe better with N chosen to be as large as practical). That way when you get short-term scrud on the line it won't show up as a clock transition and mess up your I2C logic. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.comArticle: 153288
wzab <wzab01@gmail.com> wrote: > I've found the old post: > http://www.fpgarelated.com/usenet/fpga/show/51158-1.php > pointing to http://sourceforge.net/projects/xilprg/ > I've not verified it yet with hardware, but after first look it seems > to be a good point to start. Xilinx changed there cableserver API, so xilprog doesn't work any longer with recent versions. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 153289
This could be a DCM lock problem. If the FPGA or the oscillator drift after power up, then the DCM can lose lock. If you don't have a reset circuit, the DCM will not attempt to re-lock. In the JTAG programming case, the main difference may be waiting until the board has warmed up. You can test this theory if you re-program the FPGA via the EEPROM after it has warmed up. An easy way to do that is to momentarily ground the PROGRAM_B pin. -- Gabor salimbaba wrote: > Startup clock is CCLK, config clock is default (6). > About the reset, It is defined pull down on an IO. > > Also, when I program the FPGA using EEPROM, and try to send packets through > the phyters, I get very frequent disconnections, which are not there when I > program it using JTAG. > > >> On Jan 26, 11:46=A0am, "salimbaba" >> <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >> >> What about the JTAG pins? Are they pulled up/down? If they are >> floating, your system may behave erratically. >> However if you use Chipscope, then probably JTAG pins are driven >> correctly. >> >> What about the startup clock? >> What about reset? >> That's all I can imagine now. >> -- >> HTH & Regards, >> WZab >> > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 153290
I will look into that on the weekend. Btw I lowered the Configrate from default(6) to 3 and it got programmed and working fine. Thanks a lot. >This could be a DCM lock problem. If the FPGA or the oscillator >drift after power up, then the DCM can lose lock. If you don't >have a reset circuit, the DCM will not attempt to re-lock. In >the JTAG programming case, the main difference may be waiting >until the board has warmed up. You can test this theory if you >re-program the FPGA via the EEPROM after it has warmed up. An >easy way to do that is to momentarily ground the PROGRAM_B pin. > >-- Gabor > >salimbaba wrote: >> Startup clock is CCLK, config clock is default (6). >> About the reset, It is defined pull down on an IO. >> >> Also, when I program the FPGA using EEPROM, and try to send packets through >> the phyters, I get very frequent disconnections, which are not there when I >> program it using JTAG. >> >> >>> On Jan 26, 11:46=A0am, "salimbaba" >>> <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >>> >>> What about the JTAG pins? Are they pulled up/down? If they are >>> floating, your system may behave erratically. >>> However if you use Chipscope, then probably JTAG pins are driven >>> correctly. >>> >>> What about the startup clock? >>> What about reset? >>> That's all I can imagine now. >>> -- >>> HTH & Regards, >>> WZab >>> >> >> --------------------------------------- >> Posted through http://www.FPGARelated.com > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153291
I'm guessing that the lower configrate extended the configuration time enough for the external stuff to become stable. Since you could see the ChipScope core when the FPGA did not run correctly, it's unlikely that the issue was with the bitstream loading itself. -- Gabor salimbaba wrote: > I will look into that on the weekend. Btw I lowered the Configrate from > default(6) to 3 and it got programmed and working fine. Thanks a lot. > > > >> This could be a DCM lock problem. If the FPGA or the oscillator >> drift after power up, then the DCM can lose lock. If you don't >> have a reset circuit, the DCM will not attempt to re-lock. In >> the JTAG programming case, the main difference may be waiting >> until the board has warmed up. You can test this theory if you >> re-program the FPGA via the EEPROM after it has warmed up. An >> easy way to do that is to momentarily ground the PROGRAM_B pin. >> >> -- Gabor >> >> salimbaba wrote: >>> Startup clock is CCLK, config clock is default (6). >>> About the reset, It is defined pull down on an IO. >>> >>> Also, when I program the FPGA using EEPROM, and try to send packets > through >>> the phyters, I get very frequent disconnections, which are not there > when I >>> program it using JTAG. >>> >>> >>>> On Jan 26, 11:46=A0am, "salimbaba" >>>> <a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote: >>>> >>>> What about the JTAG pins? Are they pulled up/down? If they are >>>> floating, your system may behave erratically. >>>> However if you use Chipscope, then probably JTAG pins are driven >>>> correctly. >>>> >>>> What about the startup clock? >>>> What about reset? >>>> That's all I can imagine now. >>>> -- >>>> HTH & Regards, >>>> WZab >>>> >>> >>> --------------------------------------- >>> Posted through http://www.FPGARelated.com >> > > --------------------------------------- > Posted through http://www.FPGARelated.comArticle: 153292
On Jan 26, 3:41 am, "Morten Leikvoll" <mleik...@yahoo.nospam> wrote: > "Tim Wescott" <t...@seemywebsite.com> wrote in message > > news:WNydnTO0ir1Fp73SnZ2dnUVZ_jWdnZ2d@web-ster.com... > > > On Wed, 25 Jan 2012 15:32:11 +0000, glen herrmannsfeldt wrote: > > >> Morten Leikvoll <mleik...@yahoo.nospam> wrote: > >>> Are there any simple practical [fpga internal] solutions to aviod > >>> internal "ringing" on slow (edged) clock inputs on fpga's, other than > >>> resampling and filtering in a different clock domain? (Using Altera > >>> Stratix III atm) > > >> Best to keep the slow edge out. > > >> You could connect the clock to a nearby output, with a resistor (of > >> appropriate size) to the input, to supply a little positive feedback. > >> (An additional small series resistor if the clock generator output is > >> too low impedance.) > > >> Even better is to do it before it gets to the clock input. > > > Yup. One little Schmitt trigger in an SOT-23 (or smaller) package, and > > suddenly your clock is clean (well, cleaner). > > > Or have you already gotten the board laid out and built, and now you need > > a bandaid? > > Im really just lazy.. This clock is so slow I can resample it (got a 100Mhz > available for that), but I wrote and simulated it for direct clk (it's the > SCL of a i2c bus, and to make the case even worse, its the SCL of a DVI DDC > bus wich runs on long, often bad quality wires with SDA/SCL crosstalk). > I was kinda hoping for some builtin schmitt trigger attribute that I could > assign to it. > I'll start on the resampling part right now ;p > > Thanks I tend to use a single clock domain in most of my designs. It is a nice easy thing to do from many perspectives. The exceptions include interfaces like SPI and I2C... <g> In serial interfaces, especially ones that run at faster clock rates like SPI I use the clock for the handshake and shift register and then cross the clock domain using the standard techniques. I was trying to think how you might make a Schmitt trigger in the FPGA. Just using an output with a resistor might not work well because the FPGA input is fast and the feedback would be slow. The positive feedback it would not prevent oscillations from noise for a few nanoseconds. One way that might work would add a second input pin and an output pin with a resistor and a wire. Some generations back Xilinx parts had a configurable input delay. I assume this is available on the part you are using. One input gets the delay, the other does not. The input without the delay is fed back through the output pin to provide hysteresis through the resistor. The input with the delay is the one used in the internal clock circuit. Or you might need to use a function of the two inputs to drive the output to prevent the output from toggling. Using the delay this way can prevent the feedback delay through the chip from interfering with the proper function of the hysteresis. I don't know I would ever bother doing this unless I was desperate to get something working without the sampling, but it has possibilities. RickArticle: 153293
Hi all, I have been a long time member of this group receiving 1 abridged email eve= ry day. A month ago I stopped receiving it with no reason. I unsubscribed a= nd subscribed again to the group, and made sure that my settings were corre= ct. I am using gmail as my client and I am sure that the mail is not going = to the spam folder and they are not in the all mail folder. This problem ha= s been repeated throughout all the groups I am subscribed to, mainly comp.l= ang.vhdl and sci.electronics.design. I also tried to contact google through= their help system but arrived nowhere.=20 Has anyone passed from the same experience or may offer some help? Thanks a lot, Regards, JosephArticle: 153294
I'd suggest You to use newsgroups server and newsgroup reader. I use Outlook express for that. "jozamm" <jozamm@gmail.com> wrote in message news:16058669.1907.1327647506690.JavaMail.geo-discussion-forums@yqlp13... Hi all, I have been a long time member of this group receiving 1 abridged email every day. A month ago I stopped receiving it with no reason. I unsubscribed and subscribed again to the group, and made sure that my settings were correct. I am using gmail as my client and I am sure that the mail is not going to the spam folder and they are not in the all mail folder. This problem has been repeated throughout all the groups I am subscribed to, mainly comp.lang.vhdl and sci.electronics.design. I also tried to contact google through their help system but arrived nowhere. Has anyone passed from the same experience or may offer some help? Thanks a lot, Regards, JosephArticle: 153295
Hi Tom! I have programmed the eFuse AES key of the Spartan-6 LX100 on our board using Impact 13.3 and a Platform Cable USB II. You have to connect the RFUSE pin to ground via the specified bias resistor and the JTAG cable can not be at more than 1.5 MHz, but if that is fulfilled it seems to work. At least configuration with an encrypted .bit-file passes. We use 3.3V VCCAUX, I can't remember if that is a factor... Cheers! /Lars P.S. Remove the obvious from my address if you want to email me directly. D.S.Article: 153296
Hello somebody Know how to link matlab with any device with tcp/ip comunication Iam david.Article: 153297
any comments on either VHDL or Verilog?Article: 153298
On Jan 28, 7:04=A0pm, vsh <henry.val.sc...@gmail.com> wrote: > any comments on either VHDL or =A0Verilog? VHDLArticle: 153299
Hi David, there is some tcp/ip in the instrument control toolbox. I never tried that one. markus Am 28.01.2012 21:58, schrieb david: > > > Hello somebody Know how to link matlab with any device with tcp/ip > comunication > > Iam david.
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