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
Applause!!!Article: 111051
Peter Alfke wrote: > To paraphrase Karl Marx: > A spectre is haunting this newsgroup, the spectre of metastability. > Whenever something works unreliably, metastability gets the blame. But > the problem is usually elsewhere. > > Metastability causes a non-deterministic extra output delay, when a > flip-flop's D input changes asynchronously, and happens to change > within an extremely narrow capture window (a tiny fraction of a > femtosecond !). This capture window is located at an unknown (and > unstable) point somewhere within the set-up time window specified in > the data sheet. The capture window is billions of times smaller than > the specified set-up time window. The likelihood of a flip-flop going > metastable is thus extremely small. The likelihood of a metastable > delay longer than 3 ns is even less. > As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz > clock, causes an extra 3 ns delay statistically once every billion > years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs > ten times more often, once every 100 million years. > But a 2.5 ns delay happens a million times more often ! > See the Xilinx application note XAPP094 > You should worry about metastability only when the clock frequency is > so high that a few ns of extra delay out of the synchronizer flip-flop > might causes failure. The recommended standard procedure, > double-synchronizing in two close-by flip-flops, solves those cases. > Try to avoid clocking synchronizers at 500 MHz or more... > So much about metastability. > > The real cause of problems is often the typical mistake, when a > designer feeds an asynchronous input signal to more than one > synchronizer flip-flop in parallel, (or an asynchronous byte to a > register, without additional handshake) in the mistaken believe that > all these flip-flops will synchronize the input on the same identical > clock edge. > This might work occasionally, but sooner or later subtle difference in > routing delay or set-up times will make one flip-flop use one clock > edge, and another flip-flop use the next clock edge. Depending on the > specific design, this might cause a severe malfunction. > Rule #1: Never feed an asynchronous input into more than one > synchronizer flip-flop. Never ever. > > Peter Alfke > First, I fully agree that metastability is a very rare issue, and if it _does_ occur, it is because the designer has not guarded against it. Yes - the designer has a responsibility to meet the setup and hold times (which will help prevent such issues). Second, metastability, as a potential problem, _does_ exist in any FF based system, by definition. See point number 1. So I agree with Peter Afke on this. I understand why the thread was named that way too :) I've noticed the large number of recent threads 'blaming' purported metastability issues for problems, but at (for instance) 10MHz, a metastability issue would only show up in the occasional few million or so transactions (at an absolute maximum, and then only a few times at that rate). So if there's a problem with your design throwing bad data at a rate of 1 in a million or so, check your timing. It's highly unlikely to be metastability. I have had *true* metastable problems (where an output would float, hover, oscillate and eventually settle after some 10s of *milliseconds*), but those I have seen recently don't qualify :) Cheers PeteSArticle: 111052
On 27 Oct 2006 14:25:09 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >To paraphrase Karl Marx: >A spectre is haunting this newsgroup, the spectre of metastability. >Whenever something works unreliably, metastability gets the blame. But >the problem is usually elsewhere. In my experience, ground bounce is a bigger problem. Especially in a device that is nearly 'full' it is wise to invest in a few fabricated grounds (dedicate a pin at a strategic location, i.e. as far away as possible from other ground pins, drive it to ground, and tie it to ground externally). When you find that moving cells around alleviates or intensifies observed instabilities, you may want to look into ground bounce problems. >Metastability causes a non-deterministic extra output delay, when a >flip-flop's D input changes asynchronously, and happens to change >within an extremely narrow capture window (a tiny fraction of a >femtosecond !). This capture window is located at an unknown (and >unstable) point somewhere within the set-up time window specified in >the data sheet. The capture window is billions of times smaller than >the specified set-up time window. The likelihood of a flip-flop going >metastable is thus extremely small. The likelihood of a metastable >delay longer than 3 ns is even less. >As an example, a 1 MHz asynchronous signal, synchronized by a 100 MHz >clock, causes an extra 3 ns delay statistically once every billion >years. If the asynchronous event is at 10 MHz, the 3 ns delay occurs >ten times more often, once every 100 million years. >But a 2.5 ns delay happens a million times more often ! >See the Xilinx application note XAPP094 >You should worry about metastability only when the clock frequency is >so high that a few ns of extra delay out of the synchronizer flip-flop >might causes failure. The recommended standard procedure, >double-synchronizing in two close-by flip-flops, solves those cases. I've found that one synchronizing flip-flop was not enough in one particular case (from a 4-ish to 50-ish MHz domain). Two was. Does one ever work reliably ? Or has the 'window' become smaller in the past few years ? John Kortink Windfall Engineering -- Email : kortink@inter.nl.net Homepage : http://www.windfall.nl Your hardware/software designs realised !Article: 111053
To paraphrase Karl Marx: A spectre is haunting this newsgroup, the spectre of metastability. Whenever something works unreliably, metastability gets the blame. But the problem is usually elsewhere. Metastability causes a non-deterministic extra output delay, when a flip-flop's D input changes asynchronously, and happens to change within an extremely narrow capture window (a tiny fraction of a femtosecond !). This capture window is located at an unknown (and unstable) point somewhere within the set-up time window specified in the data sheet. The capture window is millions of times smaller than the specified set-up time window. The likelihood of a flip-flop going metastable is thus extremely small. The likelihood of a metastable delay longer than 3 ns is even smaller. As an example, a close-to 1 MHz asynchronous signal, synchronized by a 100 MHz clock, causes an extra 3 ns metastable delay statistically once every billion years. If the asynchronous event is at ~10 MHz, the 3 ns delay occurs ten times more often, once every 100 million years. But a 2.5 ns delay happens a million times more often ! See the Xilinx application note XAPP094 You should worry about metastability only when the clock frequency is so high that a few ns of extra delay out of the synchronizer flip-flop might causes failure. The recommended standard procedure, double-synchronizing in two close-by flip-flops, solves those cases. Try not to use a 500 MHz clock to capture asynchronous inputs... So much about metastability. Much more common is the typical oversight, when a designer feeds an asynchronous input signal to more than one synchronizer flip-flop in parallel, in the mistaken believe that all these flip-flops will synchronize the input on the same identical clock edge. Or feed an asynchronous byte into an eight-bit register, without any additional handshake. This might work occasionally, but sooner or later subtle difference in routing delay or set-up times will make one flip-flop use one clock edge, and another flip-flop use the following clock edge. Depending on the specific design, this might cause a severe malfunction. Rule #1: Never feed asynchronous inputs into more than one synchronizer flip-flop. Never ever. Peter AlfkeArticle: 111054
Hi, I am trying to make a multi core processor design on board of virtex 4 family. I have 2 processors so i believe that I would need 2 local memory units, that is two BRAM blocks. One for each of the processor. What is happening is when i am synthesizing the design I find that I am using more number of RAMB16 primitives than what are there on the board. I am using 52 while there are just 36 on the board. I am using Xilinx Platform Studio for this purpose. It computes the BRAM block size, Address Width and Data Width on it's own. I am not sure if there is some way I can configure this. Please tell me how I can reduce the number of RAMB16 primitives that I am using. Thanks in Advance, Bhanu P.S: Board I am using is ML403 board.Article: 111055
PeteS wrote: > > I have had *true* metastable problems (where an output would float, > hover, oscillate and eventually settle after some 10s of > *milliseconds*), but those I have seen recently don't qualify :) Can you clarify the device/process/circumstances ? -jgArticle: 111056
Jim Granville wrote: > PeteS wrote: > >> >> I have had *true* metastable problems (where an output would float, >> hover, oscillate and eventually settle after some 10s of >> *milliseconds*), but those I have seen recently don't qualify :) > > > Can you clarify the device/process/circumstances ? > > -jg > This was a discrete design with FETs that I was asked to test (at a customer site). The feedback loop was not particularly well done, so when metastability did occur, it was spectacular. Cheers PeteSArticle: 111057
Evan Lavelle wrote: > Those of you with long memories may recall coding devices in ABEL. One > nice thing about ABEL was that you could write very simple vector > files to simulate your device, where a vector was something like > > [C,1,0,1,etc] -> [1,1,0,1,HHHH,01AB,etc] > > ie. setup some inputs, apply a clock pulse, and check some outputs. > I've written some software over the years that lets me do the same > thing in VHDL, with various extensions, and I use it to test most of > my RTL code. It's simple, you don't need to write or know *any* VHDL > to use it, and it gives you a pass/fail very quickly, for a module or > a whole device. This sort of test-vector entry is basically unmaintainable, and to be honest, I haven't written this type of go/no-go test in ages (maybe since the last time I used ABEL). I prefer to write test benches at a higher level. I like to have models of the things to which the DUT connects drive the DUT. For example, if my FPGA is a NAND flash controller that sits between a microprocessor bus and the NAND flash devices, I'll use a bus-functional model of the micro and the flash, and my test bench will mostly consist of MicroWriteBus() and MicroReadBus() "commands." I can't go back to the simple drive-a-vector test. -aArticle: 111058
burn.sir@gmail.com wrote: > Jan Decaluwe wrote: > (snip) > > description language. This project demonstrates that this technology > > is real and practical. > > Not really, I know a guy that built a SID clone using mostly 74xxx > parts. I also know another guy that wrote his own schematic capture in > order to design, thats right, a SID clone. Does this demonstrates that > their technology was real and practical? > Jan is talking about MyHDL itself, not PhoenixSID per se. Perhaps he could have been clearer. That said, rest assured my project is real; I even took it on the road and did a live demonstration of it at UMass Lowell (and got paid for it to boot). I'm still working on the practical part ;-) And I know I'll get there! > That page has been there for a long while. Even a basic glance at the project page would show that I've been putting in steady effort over many months of my spare time, following through on my idea, which also has consistently been demo-ready even while under development. >And I am still waiting for the source code so I can form my own opinion. 1) I have no idea who you are. Someone did ask me for it, but it surely was a different person. They were quite polite and respectful. 2) Who said you had to wait for the PhoenixSID source code to get a feel for MyHDL? It's not that hard to try it yourself. Hell, all the tools are free: Python, MyHDL, even Xilinx WebPACK ISE The Digilent Spartan3 board can be had for as little as $99. The MyHDL cookbook (easily accessible from the front page of the Wiki) contains examples that range from simple D-flip flops all the way to a Cordic Sine Computer and a recursive Bitonic Sorter. The tutorials are rich in detail and insight. The knowledge they contain can readily be used to make your own, more complex designs. Often, the full design flow from MyHDL->Verilog->FPGA (including unit tests) is shown. Try starting off with a blinking LED demo. That's what worked for me. 3) I spent months of my free time working hard and continually learning to create PhoenixSID, and I had tons of fun in the process. I learned far, far more than how to build a "SID clone". Among the things I've learned are serious Python skills, digital hardware design, analog hardware design, synthesizer design, widely applicable engineering skills, problem solving, stress management, how to stay motivated and follow through on a long-term, difficult goal, people and presentation skills, how to combine my love of music with my love of electronics and engineering in a productive way and I even had some valuable insights about life in general along the way. Why do you feel entitled to my source code? What have you contributed? Even though I'm still considering my license options I still want to share my knowledge somehow. So, in the meantime, I'd like to write some tutorials for the website. Also, I'm working on the MyHDL Booster package (see below), which will be open and free. I'm a busy person so that may be a little while still. Also, I'm planning a huge improvement to PhoenixSID that requires significantly more complexity in the hardware invloved. Rather than blindly jump into that, I've been experimenting with techniques to simplify and streamline the process and make it much more fun. To make sure MyHDL Booster will be applicable to a real project and not just an academic exercise, I'm working on it in tandem with real, synthesizable, working examples, (including the next upgrade to PhoenixSID) and using the feedback to improve MyHDL Booster. This takes time, effort, imagination, insight, patience and persistence. George, are you > listening? > Besides all the work mentioned above, I've been holding down a full-time engineering job with a major company, practicing guitar, taking voice lessons, playing in a band and keeping up an active social life. I don't have time for people who troll newsgroups instead of offering constructive feedback. Be clear, respectful and specific with your questions and feedback, do your homework and have something to offer. Then we'll talk. Rock on, George Pantazopoulos http://www.gammaburst.netArticle: 111059
Our server did strange things, like filing my (long) posting twice... The numbers I quoted are from experiments with VirtexIIPro, a few years ago. (XAPP094) So it's modern, but not very modern. Old horror stories of millisecond oscillations must have been based on TTL circuits, where there are multiple slow stages in the master-latch feedback loop (the only participant in metastability delays).Modern CMOS flip-flops are much simpler, and I have never heard about them oscillating due to metastability. There is a human tendency to blame every evil on the mystery du jour. Metastability is not mysterious, but it is rare and non-deterministic, which bothers some people... I agree that ground bounce a.k.a. simultaneously switching outputs (SSOs) is a far nastier problem. Peter Alfke Peter Alfke wrote: > To paraphrase Karl Marx: > A spectre is haunting this newsgroup, the spectre of metastability. > Whenever something works unreliably, metastability gets the blame. But > the problem is usually elsewhere. > > Metastability causes a non-deterministic extra output delay, when a > flip-flop's D input changes asynchronously, and happens to change > within an extremely narrow capture window (a tiny fraction of a > femtosecond !). This capture window is located at an unknown (and > unstable) point somewhere within the set-up time window specified in > the data sheet. The capture window is millions of times smaller than > the specified set-up time window. The likelihood of a flip-flop going > metastable is thus extremely small. The likelihood of a metastable > delay longer than 3 ns is even smaller. > As an example, a close-to 1 MHz asynchronous signal, synchronized by a > 100 MHz clock, causes an extra 3 ns metastable delay statistically once > every billion years. If the asynchronous event is at ~10 MHz, the 3 ns > delay occurs ten times more often, once every 100 million years. > But a 2.5 ns delay happens a million times more often ! > See the Xilinx application note XAPP094 > You should worry about metastability only when the clock frequency is > so high that a few ns of extra delay out of the synchronizer flip-flop > might causes failure. The recommended standard procedure, > double-synchronizing in two close-by flip-flops, solves those cases. > Try not to use a 500 MHz clock to capture asynchronous inputs... > So much about metastability. > > Much more common is the typical oversight, when a designer feeds an > asynchronous input signal to more than one synchronizer flip-flop in > parallel, in the mistaken believe that all these flip-flops will > synchronize the input on the same identical clock edge. Or feed an > asynchronous byte into an eight-bit register, without any additional > handshake. > This might work occasionally, but sooner or later subtle difference in > routing delay or set-up times will make one flip-flop use one clock > edge, and another flip-flop use the following clock edge. Depending on > the specific design, this might cause a severe malfunction. > Rule #1: Never feed asynchronous inputs into more than one synchronizer > flip-flop. Never ever. > > Peter AlfkeArticle: 111060
> The V4 should have no trouble whatsoever driving a 2m camera link (3M MDR > type) cable. Yes I thought it was a no brainer. >I currently have a design using a V2PRO30 that drives 5m of cable. The >differential pins are driven by the below module. I think my VHDL is similar. What is your FPGA editor showing when you go to those pins? Mine shows two pads, a master and a slave. When I push into these pads I don't see any options checked. Do you have additional stuff in your UCF file? Thanks, Brad Smallridge > > Take care, > Rob > > > module diff_outbuf_single(in, p_out, n_out); > input in; > output p_out; > output n_out; > > OBUFDS inst1 ( > .O(p_out), // Diff_p output(connect directly to top-level port) > .OB(n_out), // Diff_n output (connect directly to top-level port) > .I(in) // Buffer input > ); > > endmodule > > > "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message > news:12k1op3ddh0iea@corp.supernews.com... >> Can anyone tell me what I need to drive a Camera Link >> output directly from a V4? I have tried LVCMOS25 and I >> can see differential signals at the outputs but at the >> end of a 2 meter cable I see only DC differential levels >> as if the signals are dampened somehow. >> >> Brad Smallridge >> aivision >> >> > >Article: 111061
PeteS wrote: > Jim Granville wrote: > >> PeteS wrote: >> >>> >>> I have had *true* metastable problems (where an output would float, >>> hover, oscillate and eventually settle after some 10s of >>> *milliseconds*), but those I have seen recently don't qualify :) >> >> Can you clarify the device/process/circumstances ? >> >> -jg >> > > This was a discrete design with FETs that I was asked to test (at a > customer site). The feedback loop was not particularly well done, so > when metastability did occur, it was spectacular. Do you mean they built a D-FF, using discrete FETS ?! I have seen transistion oscillations (slow edges) cause very strange effects in Digital Devices, but I'd not call that effect metastability. -jgArticle: 111062
Hi,
I am learning VHDL from Mike's example Uart.vhd in ISE 8.2. For
behavioral simulation, I can run Modelsim smoothly. But for other
simulation, such as post-translate or post-route simulation, there are
the following warnings:
# Reading C:/Modeltech_xe_starter/tcl/vsim/pref.tcl
# do {test_uart.ndo}
# ** Warning: (vlib-34) Library already exists at "work".
# Model Technology ModelSim XE III vcom 6.1e Compiler 2006.03 Mar 8
2006
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Loading package vital_primitives
# -- Loading package textio
# -- Loading package vpackage
# -- Compiling entity uart
# -- Compiling architecture structure of uart
# Model Technology ModelSim XE III vcom 6.1e Compiler 2006.03 Mar 8
2006
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package numeric_std
# -- Loading package uart_pkg
# -- Compiling entity test_uart
# -- Compiling architecture sim of test_uart
# -- Loading package vital_timing
# -- Loading package vcomponents
# -- Loading package vital_primitives
# -- Loading package textio
# -- Loading package vpackage
# -- Loading entity uart
# ** Error: test_uart.vhd(110): (vcom-1136) Unknown identifier
"char_len_g".
# ** Error: test_uart.vhd(111): (vcom-1136) Unknown identifier
"tic_per_bit_g".
# ** Error: test_uart.vhd(407): VHDL Compiler exiting
# ** Error: C:/Modeltech_xe_starter/win32xoem/vcom failed.
# Error in macro ./test_uart.ndo line 7
# C:/Modeltech_xe_starter/win32xoem/vcom failed.
# while executing
# "vcom -explicit -93 "test_uart.vhd""
After I check the library work, I find the work.uart (for other than
behavioral simulation) does not have char_len_g anymore (only the
source, i.e. behavioral file has that generic definition). How to deal
with this?
Thank you in advance.
>From test_uart.vhd:
begin -- architecture sim
dut : entity work.uart
generic map (char_len_g => tb_char_g, -- for vsim command line
overload
tic_per_bit_g => tb_tics_g)
Article: 111063Well, in the beginning of my professional life, I built flip-flops out of two Ge transistors, 8 resistors, two diodes and two capacitors. Remember, the term J-K flip-flop comes from a standardized sinle-FF pc-board where the connector oins were labeled A-Z, and the set and reset inputs were on the adjacent central pins J and K. Not a joke... Peter Alfke On Oct 27, 4:53 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > PeteS wrote: > > Jim Granville wrote: > > >> PeteS wrote: > > >>> I have had *true* metastable problems (where an output would float, > >>> hover, oscillate and eventually settle after some 10s of > >>> *milliseconds*), but those I have seen recently don't qualify :) > > >> Can you clarify the device/process/circumstances ? > > >> -jg > > > This was a discrete design with FETs that I was asked to test (at a > > customer site). The feedback loop was not particularly well done, so > > when metastability did occur, it was spectacular.Do you mean they built a D-FF, using discrete FETS ?! > > I have seen transistion oscillations (slow edges) cause very strange > effects in Digital Devices, but I'd not call that effect metastability. > > -jgArticle: 111064
Peter Alfke wrote:
>
>This is the official answer from our support organization:
<snip>
> "use our great WebCase tool"
>
Describing WebCase as "great" for documentation errors
is (cough, hack) a bit of a stretch; have you ever filed one ?
( If not, the next time you find and report, say, a particularly
sneaky FIFO flag bug, wait a few months for your internal
paperwork mill to grind- then pseudonymously file a WebCase
describing exactly that same problem, and see what happens... )
Filing documentation error reports through a WebCase
is particularly time consuming and pointless;
my experience has been that Xilinx essentially refuses
to fix the documentation problems no matter how
painstakingly detailed the report.
The WebCase will be closed as rapidly as possible by Xilinx,
possibly without the first responder even understanding the
documentation problem.
If you are persistent, you can get some CR's filed, at which
point the WebCase will then be closed; none of that persistence
will result in any good, as the CR's then vanish into the mists.
Post-WebCase, nothing happens:
- datasheet errors and omissions persist
- Answer Records remain incorrect
- software bugs remain
( or perhaps worse, reappear in a version or two )
At best, years later there may appear a cryptic Answer Record
or an indecipherable footnote that bears almost no resemblance
to the original problem report.
AFAIK, there's no way to track a CR's status without
opening a new WebCase and asking again; if you're lucky,
the link on your WebCase history page may actually display
the old WebCase text without locking up your browser.
And to top it all off, if you then post a summary of said
problems here on comp.arch.fpga, you run the risk of being
flamed by Xilinx's own Troll of Implausible Deniability.
Brian
Article: 111065I see the same thing you do within the editor, master and slave pads. Both pads have an IO standard of LVDS_25. I have nothing else in my UCF file pertaining to these pins. Is you sure your bank voltage being powered by 2.5V? "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:12k56ahdpboge63@corp.supernews.com... > >> The V4 should have no trouble whatsoever driving a 2m camera link (3M MDR >> type) cable. > > Yes I thought it was a no brainer. > >>I currently have a design using a V2PRO30 that drives 5m of cable. The >>differential pins are driven by the below module. > > I think my VHDL is similar. What is your FPGA editor showing > when you go to those pins? Mine shows two pads, a master and > a slave. When I push into these pads I don't see any options > checked. Do you have additional stuff in your UCF file? > > Thanks, > Brad Smallridge > >> >> Take care, >> Rob >> >> >> module diff_outbuf_single(in, p_out, n_out); >> input in; >> output p_out; >> output n_out; >> >> OBUFDS inst1 ( >> .O(p_out), // Diff_p output(connect directly to top-level port) >> .OB(n_out), // Diff_n output (connect directly to top-level port) >> .I(in) // Buffer input >> ); >> >> endmodule >> >> >> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message >> news:12k1op3ddh0iea@corp.supernews.com... >>> Can anyone tell me what I need to drive a Camera Link >>> output directly from a V4? I have tried LVCMOS25 and I >>> can see differential signals at the outputs but at the >>> end of a 2 meter cable I see only DC differential levels >>> as if the signals are dampened somehow. >>> >>> Brad Smallridge >>> aivision >>> >>> >> >> > >Article: 111066
> require less than 1,000 writes, you could use the flash. It's not a matter of the number of writes. It is a matter of where to write. I don't need to change the flash bits that control the FPGA, I need other flash area that is unused by the FPGA. They tell me that in the XO and XP all of the flash bits are used to config the FPGA. There is no extra space. If I write in that, then the FPGA logic will be messed up. > since you want to turn off the part and reconfigure? No, I don't want to recofigure the FPGA. I need to store serial numbers and calibration data on the product somewhere. The FPGA code itself is not going to change. The point is this: Lattice thinks that it's a big advantage having built-in flash that you don't need an external memory part like the Altera or Xlinix. Well that's only true if you don't need to store some other stuff in NV memory also. If you do, then the advantage is lost because you have to add an external memory anyway. Whether the external mem chip is $0.40 (8K EEPROM) or $0.75 (1M-SPI) is no big deal. It doesn't save much, and no board space at all. Lattice would have been miles ahead if they would have left some extra space besides what the FPGA uses in their onboard flash. They now know that all too well, and in the XP-II parts coming out next quarter there will be extra flash space. The big advantage Lattice has right now is single supply. That may make the difference between a 4 layer board and double sided board in my case, and that difference pays for the entire FPGA. That is a real big deal. Single supply is probably the most cost saving feature in these cases where a multilayer board is not needed for much else than the FPGA. Thanks, Chris.Article: 111067
Brian, in spite of (or because of) your nasty tone, I will on Monday submit this to the responsible group in Xilinx support. Just a few comments: Not everything is just a documentation fault. The unfortunate and very subtle Virtex-4 FIFO flag problem haunted us for many weeks, until we had found the cause and a barely acceptable work-around. (I was in the middle of it, and still have the mental scars). The System Monitor design had a subtle problem that caused us to delete it from Virtex-4 documentation. Now that it is fixed, we re-introduced it in Virtex-5LXT. And Virtex-4FXMGTs had more than their share of difficulties... As FPGAs have changed from being a "homogeneous sandbox" to a diverse mixture of highly complex and specific system blocks, the testing, guaranteeing and documenting of operation under a wide variety of user circumstances has become increasingly challenging. You can be sure that we try our best, even when that sometimes is not good enough. Peter Alfke, definitely not a "Troll of Implausible Deniability". ==================================== On Oct 27, 5:42 pm, "Brian Davis" <brimda...@aol.com> wrote: > Peter Alfke wrote: > > >This is the official answer from our support organization: > <snip> > > "use our great WebCase tool" Describing WebCase as "great" for documentation errors > is (cough, hack) a bit of a stretch; have you ever filed one ? > > ( If not, the next time you find and report, say, a particularly > sneaky FIFO flag bug, wait a few months for your internal > paperwork mill to grind- then pseudonymously file a WebCase > describing exactly that same problem, and see what happens... ) > > Filing documentation error reports through a WebCase > is particularly time consuming and pointless; > my experience has been that Xilinx essentially refuses > to fix the documentation problems no matter how > painstakingly detailed the report. > > The WebCase will be closed as rapidly as possible by Xilinx, > possibly without the first responder even understanding the > documentation problem. > > If you are persistent, you can get some CR's filed, at which > point the WebCase will then be closed; none of that persistence > will result in any good, as the CR's then vanish into the mists. > > Post-WebCase, nothing happens: > - datasheet errors and omissions persist > - Answer Records remain incorrect > - software bugs remain > ( or perhaps worse, reappear in a version or two ) > > At best, years later there may appear a cryptic Answer Record > or an indecipherable footnote that bears almost no resemblance > to the original problem report. > > AFAIK, there's no way to track a CR's status without > opening a new WebCase and asking again; if you're lucky, > the link on your WebCase history page may actually display > the old WebCase text without locking up your browser. > > And to top it all off, if you then post a summary of said > problems here on comp.arch.fpga, you run the risk of being > flamed by Xilinx's own Troll of Implausible Deniability. > > BrianArticle: 111068
Chris wrote: >>require less than 1,000 writes, you could use the flash. > > > It's not a matter of the number of writes. It is a matter of where to > write. I don't need to change the flash bits that control the FPGA, I need > other flash area that is unused by the FPGA. They tell me that in the XO > and XP all of the flash bits are used to config the FPGA. There is no extra > space. If I write in that, then the FPGA logic will be messed up. > > >> since you want to turn off the part and reconfigure? > > > No, I don't want to recofigure the FPGA. I need to store serial numbers and > calibration data on the product somewhere. The FPGA code itself is not > going to change. Lattice offer Soft CPUs like the Mico8 and they need to store the Opcodes in ROM. That means there must be an Opcode-> ROM pathway, for their parts ( ie using BRAM as ROM ). Why not look at the Mico8 flows for that, and put your Serial#/Calibration infos into the psuedo ROM space ? -jgArticle: 111069
Jawbreaker wrote: > burn.sir@gmail.com wrote: > > Jan Decaluwe wrote: > > (snip) > > > description language. This project demonstrates that this technology > > > is real and practical. > > > > > Not really, I know a guy that built a SID clone using mostly 74xxx > > parts. I also know another guy that wrote his own schematic capture in > > order to design, thats right, a SID clone. Does this demonstrates that > > their technology was real and practical? > > > > Jan is talking about MyHDL itself, not PhoenixSID per se. Perhaps he > could have been clearer. > > That said, rest assured my project is real; I even took it on the road > and did a live demonstration of it at UMass Lowell (and got paid for it > to boot). I'm still working on the practical part ;-) And I know I'll > get there! > > > That page has been there for a long while. > > Even a basic glance at the project page would show that I've been > putting in steady > effort over many months of my spare time, following through on my idea, > which also > has consistently been demo-ready even while under development. > > >And I am still waiting for the source code so I can form my own opinion. > > 1) I have no idea who you are. Someone did ask me for it, but > it surely was a different person. They were quite polite and > respectful. > > 2) Who said you had to wait for the PhoenixSID source code to get a > feel for MyHDL? > > It's not that hard to try it yourself. > Hell, all the tools are free: Python, MyHDL, even Xilinx WebPACK ISE > The Digilent Spartan3 board can be had for as little as $99. > > The MyHDL cookbook (easily accessible from the front page of the Wiki) > contains examples that range from simple D-flip flops all the way to a > Cordic Sine Computer and a recursive Bitonic Sorter. > > The tutorials are rich in detail and insight. The knowledge they > contain can readily be used to make your own, more complex designs. > Often, the full design flow from MyHDL->Verilog->FPGA (including unit > tests) is shown. > > Try starting off with a blinking LED demo. That's what worked for me. > > 3) > I spent months of my free time working hard and continually learning to > create PhoenixSID, and I had tons of fun in the process. > > I learned far, far more than how to build a "SID clone". > Among the things I've learned are serious Python skills, digital > hardware design, analog hardware design, synthesizer design, widely > applicable engineering skills, problem solving, stress management, how > to stay motivated and follow through on a long-term, difficult goal, > people and presentation skills, how to combine my love of music with my > love of electronics and engineering in a productive way and I even had > some valuable insights about life in general along the way. > > Why do you feel entitled to my source code? What have you contributed? > > Even though I'm still considering my license options I still want to > share my knowledge somehow. So, in the meantime, I'd like to write some > tutorials for the website. Also, I'm working on the MyHDL Booster > package (see below), which will be open and free. I'm a busy person so > that may be a little while still. > > Also, I'm planning a huge improvement to PhoenixSID that requires > significantly more complexity in the hardware invloved. Rather than > blindly jump into that, I've been experimenting with techniques to > simplify and streamline the process and make it much more fun. > > To make sure MyHDL Booster will be applicable to a real project and not > just an academic exercise, I'm working on it in tandem with real, > synthesizable, working examples, (including the next upgrade to > PhoenixSID) and using the feedback to improve MyHDL Booster. This takes > time, effort, imagination, insight, patience and persistence. > > > George, are you > > listening? > > > > Besides all the work mentioned above, I've been holding down a > full-time engineering job with a major company, practicing guitar, > taking voice lessons, playing in a band and keeping up an active social > life. > > I don't have time for people who troll newsgroups instead of offering > constructive feedback. > > Be clear, respectful and specific with your questions and feedback, do > your homework and have something to offer. > > Then we'll talk. > > Rock on, > George Pantazopoulos > http://www.gammaburst.net Hey I must congratulate you. The SID was one of the best sounding synthesizer chips during the early 80s. Though I must say that it is no match for the FM synthesizers though. The fidelity on FM synthesizers was unmatched by the sampled crap in the SNES and other systems. I seem to remember the original SID chip had somewhat of a bug in which many composers exploited to produce the drum sound. Something to do with changing an amplitude register? >From what I know about the chip it had a pretty complex feature set: Envelope Control (unheard of in other PSG's) and Pulse Width Modultion (Makes some interesting sounds). May I ask, have you tried some tunes in your simulator? All you need is a 6502 CPU emulator to run the C64 code for the synth control. You can find many free emulators or you can make your own in Python. The 6502 core is quite simplistic. Also how did you make the DAC? I still dont understand how to do that with an FPGA, gotta read up on it. Or did you just generate the waveforms for each channel seperately and summed them up w/ analog circuity? I look forward to developments on your project. -IsaacArticle: 111070
> > What I'd really like to find out, if you can spare the time and this > might be of interest to you, is: > > * What simulator do you use? NC-Verilog > > * Is your RTL code in Verilog/VHDL/both? Verilog > > * Does your simulator have a C-language interface? From Verilog, or > VHDL, or both? I'm sure it does > > * If your simulator doesn't support C, would you be willing to upgrade > it to use a product of this sort? Or would you prefer to get pure VHDL > or Verilog out of this software, even if it means reduced vector file > functionality? Frankly, as an ASIC designer. I probably wouldn't use this language. In the future, we plan to use System Verilog. > > As a bonus, if you add the line "this is a great idea and I claim my > 50% discount", then you can have 50% off the (initial) purchase price, > if I ever get around to doing this. > > You can reply here or directly to me at 'unet+50' 'at' > 'riverside-machines' 'dot' 'com'. > > Thanks - > > EvanArticle: 111071
This is clearly Metastabilty issue. Thomas is correct. I was also having such kind of problem. There is an interesting article in cadence on Metastability & Cross Clock domain. If you have time, go through it http://www.cadence.com/whitepapers/cdc_wp.pdf Regards, Krishna Janumanchi Helen wrote: > Thanks Thomas - I will try this!Article: 111072
Hi,there is any Stratix II user here? I'm involved in a hardware design for an EP2S90 device. I didn't ever used such a beast but I have some serious background in analogic/logic/RF design. I've downloaded everything I found from the Altera site but the information is huge and not very well organised in those books. The questions would be: - which is the most common configuration methode you'll choose for a Stratix II (would be the AS a good choice or better the PS, assuming there is a PCB space constrain and starting time is not an issue) - for an active serial configuration: a. you'll use the download cable port for the serial FLASH config device every time you'll change the configuration ? or b. you may change the configuration with the JTAG for software test purposes and burning the flash will be the last operation and it will be quite rarely ? - how you'll choose the input and output ports (regarding to banks and quadrants) if you'll need to implement a complex math including DSP operations (FIR, matrix, etc) ? c. there are restrictions for such operations in using the banks of one quadrant for input and banks from other quadrant for the outputs (or banks for the same quadrand, but using huge number of LABs from different quadrant d. there are restrictions in sending data from one quadrant to other quadrant ( like from Q1 to Q3 for example? - how you'll use the FPGA (and clocks) if a part of it must act as a FIFO between two different speed systems any help appreciated thx, VasileArticle: 111073
Isaac Bosompem wrote: > Also how did you make the DAC? I still dont understand how to do that > with an FPGA, gotta read up on it. A very simlpe concept is this: http://www.fpga4fun.com/PWM_DAC.html -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 111074
vasile wrote:
> - which is the most common configuration methode you'll choose for a
> Stratix II
It depends what else is on the board.
If there is a cpu and flash file system,
loading the fpga image is just one of
many initialization tasks, and I can
ftp an fpga image file directly to
the embedded kernel whenever I like.
> - how you'll choose the input and output ports (regarding to banks and
> quadrants)
I like to write and sim the hdl code first
and then let place and route take the first
cut at picking pins.
-- Mike Treseler
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