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
Just a thought, but when I was a EE undergraduate back in the 80's, most of our degree course was graded by examinations. Seems to me that, provided you don't allow usenet in the examination room, this prevents all this cheating? Cheers, Syms.Article: 97276
No, you cant use FPGA alone, if you want DVI-LVDS take a TI DVI receiver, chances are that you can connect the display to it almost directly there was an project with free PCB design for this kind of converter but unfortunatly I cant find the link any more. optionally you may use FPGA *after* the DVI receiver if needed for some reason. AnttiArticle: 97277
What you have is two FF driving the same wire, which is not allowed and not synthesizable. That has nothing to do with the clock. Eventhough you have the same clock, it is still not synthesizable. HendraArticle: 97278
To observe DDR signals with a scope, you already need a good scope ...Article: 97279
You have to do all the operation in a signal process ... like (VHDL sorry ...) process (clka, clkb) begin if rising_edge(clka) then if clken_a = '1' then ... end if; end if; if rising_edge(clkb) then if clken_b = '1' then ... end if; end if; end if;Article: 97280
Not necessarily. Homework problems and test problems are two different animals. Homework is more time consuming and detailed. Test problems are necessarily terse such that with sufficient review of previous class tests(at your school or others) one can do fine on the exam without really knowing the material. Personally, I think the uproar over cheating is overblown. I can tell in about 5 minutes whether a prospective engineering hire knows what he's talking about or not. I don't think cheaters last long in our profession. -Clark "Symon" <symon_brewer@hotmail.com> wrote in message news:43f9b4ea$0$15790$14726298@news.sunsite.dk... > Just a thought, but when I was a EE undergraduate back in the 80's, most of > our degree course was graded by examinations. Seems to me that, provided you > don't allow usenet in the examination room, this prevents all this cheating? > > Cheers, Syms. > > >Article: 97281
The product is Broaddown4 due for release very shortly. Details will appear in probably 3-4 weeks time on the website. John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1140427515.806086.128880@z14g2000cwz.googlegroups.com... > send a mail to ur company address and the mail address provided in the > groups profile. > Any way i found no virtex 4 based board on your site. I want a virtex 4 > based board. And there should be provision for connecting 400 pin > processor directly to the FPGA. Also there should be an SD RAM or > provision to add one. I am ready to implement a sd ram controller in > the virtex 4. Please consider this as an urgent thinh. Thank you very > much for your response. > regards > Sumesh v S >Article: 97282
Thanks for the reply, Antti. I have seen the TI DVI reciever chip and it seems quite complex. Do you know why this is required? Would it be easier to convert from a VGA signal? I would need ADCs then - I just assumed it would be simpler to convert a signal that's already digital.Article: 97283
Hi Symon Not so long ago both the US NBC and ABC networks ran eye opening 1hr specials on cheating at every school level but esp college in the US v say a high school in Belgium. The avg Belgian kids made the US kids look like total idiots, so Belgium is still far behind the stupidity curve. Back when I was in fear of some of my teachers, caning was still a good possibility and was used for cheating, and I am not talking about Tom Brown school days, just late 60s to 70s in UK. Today I hear UK teachers get into career threating deep shxt if they point a finger! These two specials really wakened me up to this rampant plagiarism considered to be now okay, "if I don't do it, the other guys will get ahead of me". The Profs seem to have given up and are powerless. They showed the college kids using cellphones in text modes passing messages back & forth in the exam room thumbing away under the table. They showed some kids with jumbo calculators that switched into full wireless net connected PCs using them in the exam room, flipping to calc screen when examiner walked by. I will be putting my triplets into school soon enough and we are looking for a school system with no computers, just teachers, going to be quite difficult in the US. Maine and other states are forcing parents to buy expensive iBooks from a very early age, what a joke. god what have we done! John Jakson transputer guyArticle: 97284
Brendan Illingworth wrote: > Hi All, > > This post pertains to a DDR SDRAM controller that works perfectly for 95% of > DIMMS used, and is part of a test system that contains a 2+ GHz oscilloscope > monitoring the clock, command, and dqs signals at the DIMM pins. > > Several DIMMs seem to operate incorrectly only occassional (possibly > temperature dependent), and I suspect that the issue is some type of timing > requirement that is on the edge of met and violated. When the incorrect > behavior is seen the scope verifies that write cylces are operating > correctly but that the read cycles are not operating correctly. Durring the > read cycles the active command is issued, then the read command (satisfying > Trcd) and accordingly the DQS signals are provided by the DIMM. Here is the > catch; bursts of 8 was specified durring initialization and the DQS signals > durring correct operation correspond to this choice; however, but durring > the failing read cycles I will see sometimes 1 DQS rising edge, sometimes 2 > and sometimes even 5 rising edges! My questions are as follows: > > 1) Has anyone with DRAM exprience seen any behavior like this before? > > 2) ** What might cause a DDR module to provide a varying number of DQS > strobes? ** > > Recall that the design has no blatent errors since for most DIMMs no errors > are ever seen. > > Thanks for any thoughts, > > Brendan Illingworth Most DDR problems are on the read cycle. When you do a read, DDR (unlike other memory) drives not only the bus but also the strobes (as you are clearly know). What you may not know is the amount of variance there can be between devices on the DQS <-> data jitter and DQS (read) - clock variance. For those DIMMs you are having problems with, the issue is very likely that DQS is being asserted outside your timing window (so the device is, in fact, asserting a burst of 8 - you simply are not catching it). I have seen this behaviour using commercial parts with DDR controllers built in - the programmable parameters such as DQS skew being there to get around issues just such as this. The causes for this are usually either poor clock/data termination (and in DDR you have to have something even if it's only series, which is do-able in point to point), excessive round trip delay on the clock, excessive added data skew (across D0-Dn vs. DQS) or excessive skew on DQS vs. clock (which moves DQS as received away from the clock) as seen at the receiver. In addition, DDR is not specified to operate below certain speeds, although *most* will. This is a classic gotcha where the internal DLLs won't properly lock to generate read DQS appropriately. The temperature dependency is perhaps to be expected - all logic devices tend to operate a little slower (edge response in particular, but propagation delay tends to increase as well), thus increasing the amount of time before a return DQS is asserted. My first place to look would be DQS skew timing (remembering that the memory device will assert DQS at the leading edge of data - it's up to the controller to determine how to use it to grab the data) in the controller. It took me almost as long, perhaps longer, to set the rules for laying out DDR (I put down 3 independent 200/400 systems on one board) as it did to get it laid out. Even then, my timing budget had about 200 picoseconds of guaranteed margin - just what the guaranteed margin is on any particular DIMM is I can't say without a datasheet handy. Cheers PeteSArticle: 97285
no an Analog VGA to digital is almost even more complex, there is almost only chip available for purchasing (ADI sells only for 20K+ year customer) the available chip is Averlogic AL875, but unfortunatly it is missing internal PLL so you need additionally ICS1523 or similar - I have the Averlogic ADC but not the PLL so cant test it - (I have a pending design inquiry for VGA to usb conversion) the TI chip is actually pretty simple, the board that I was referring too had pretty much only the TI chip and connectors on the board AnttiArticle: 97286
there is no real good answer, - pricing differs. for the parts you asked the package price is already heavily in count not only the logic cell count Lattice ECP2 - only the ECP2-50 is currently sampling so there is no one using the ECP2-12 part yet. For Lattice their claim is that EC pricing will beat or meat any Spartan3 pricing for similar density(unless Xilinx is selling at dumping prices), and that EC is 50% cheaper than ECP Altera pricing is agressive as well, so it really depends on the disti and your project how good pricing you can get. S3-1000 could go to around 20USD(depending on package), ECP2-12 price from rule of thumb should be 12 USD (lowest speed, cheapest package), your package selection is more expensive so it may add up significant price numbers :( dont know if it helps you any - you possible are better off to decide from the features and support and availability. If you can wait for ECP2-12 part then that has some of the best features for low cost FPGA (nonvolatile secure key, SPI multi-boot, DDR2 support, etc), if you need sooner than that then try get S3 pricing down to what you need. Digikey and vendor online pricing are no good for the best price you can get, at the end you still end up talking to the disti AnttiArticle: 97287
Maybe there is a market for a new "cheating jammer" device. Disrupt all bluetooth traffic and the like. Of course then the FCC will hunt you down... As for the state of the copy/paste generation, I think it's getting pretty bad. Just look at blogs. No one really ever says anything of substance, they just read news stories, post the link and then write two sentences about their first impression. I'm sure the same thing goes for students looking for answers on google. However, being a fifth year EE student who has worked for 2.5 years also, I can tell you that kind of stuff does not fly at all once you hit the real world. This will translate into a sharper learning curve for the new graduates, and possibly an advantage for those who do stay in school a little longer (something I have not yet chosen to do). I may google for bits of code here and there, but I would never think to not first understand the underlying principles and then change it to suit my needs. I may wikipedia for general definitions (by far one of my fav sites), but would never trust it enough to put it in a report to my boss without cross referencing in a book. I have found that books are truly my friends, especially after having inherited a large DSP book collection. I am not able to get the direct answers I want, but I get the techniques I need. And isn't that what learning is all about anyway? So while I agree that cheating in schools is rampant, I think that by perhaps making the homeworks more dynamic (more than one answer) and challenging, it could teach students to use the internet to their advantage (see above). As for the Russian dude, I applaud his entrepreneurialship and encourage him to dumb down all those stuck up little rich kids who have it driven into their heads that they don't need to work hard to get anywhere in life. I think the main thing here is that parents do need to press for better teachers. But it can't stop there. There have to be more initiatives like FIRST, the Dean Kamen started foundation based around creating interest in engineering for students from a young age. The parents of engineers need to foster this lust for knowledge in not just their own children, but their entire school. ChrisArticle: 97288
Hi, I recently started working with the icap port and have incorporated it into my PPC design using xilinx XPS, and have successfully got it to reconfigure LUT's etc. using "XHwIcap_SetClbBits". What i'm trying to understand is how do i reference this LUT in the design, i.e. how do i set its inputs and read the outputs? Also it says that you can't reconfigure a slice which is being used by the design so how can you determine where a specific block of code will be stored. ShaneArticle: 97289
I have set up a ILA and ICON core in my design and connected them together as required. When I run Chipscope Analyzer it finds the core and allows me to set up the trigger. The trigger is 8 bits of which the top 3 bits are unused (so in my VHDL I have tied them to 0), data to capture is set to the same as the trigger. When I capture some data I have unexpected activity on my signals, including the 3 bits that are tied to 0 in the VHDL!!! How is it possible to see activity on the top 3 bits of the trigger/data when they are tied to 0? Obviously now I have no faith in the signals that are attached to the other 5 bits of the trigger/data. Anyone else experienced this? Cheers SimonArticle: 97290
Hi, I know that you can use a Tcl script to add pin assignments, by using the "cmp add_assignment" command. Is there a similar command for removing pin assignments? Thanks, ErnieArticle: 97291
Traditionally, firmware was defined as software that resided in ROM. So, my question is, what do you call FPGA code? Is "firmware" appropriate?Article: 97292
Thanks to all guys! For observing signals with an oscilloscope I really need a good one but I found just an ordinary one. It does not seem to be very useful. I also tried different DCM's PHASE_SHIFT values. I read a different data but no correct one. So it was not the key. Could someone tell me about data IO's? I read that all data IO's must use both INFFs, OUTFFs and one of the Tristate-FFs (one could see it in mapper report). For me all data IO's use only OUTDDR...I am confused.Article: 97293
ada schrieb: > Thanks to all guys! > > For observing signals with an oscilloscope I really need a good one but I > found just an ordinary one. It does not seem to be very useful. I also Those terms are not quite tecnically. An ordinary scope of today was a high end scope 5 years ago. What you need is some numbers. Last time I had a look at a DDR RAM interface I was using a 1.5 GHz scope form Agilent with 2.5 GHz active probes. Worked fine. Anyone had success using less firepower? > tried different DCM's PHASE_SHIFT values. I read a different data but no > correct one. So it was not the key. > > Could someone tell me about data IO's? I read that all data IO's must use > both INFFs, OUTFFs and one of the Tristate-FFs (one could see it in mapper > report). For me all data IO's use only OUTDDR...I am confused. This is just fine, OUTDDR are OUTFFs. Regards FalkArticle: 97294
Marko schrieb: > Traditionally, firmware was defined as software that resided in ROM. > So, my question is, what do you call FPGA code? Is "firmware" > appropriate? Why not? Regards FalkArticle: 97295
>I am therefore trying to build a so-called "two-modulus prescaler" >PLL. In other words, I would like to use the FPGA's internal logic >in order to build a frequency divider that toggles between >division by N and division by N-1. By adjusting the duty cycle >of the divider toggling signal, I should be able to achieve >output frequencies corresponding to high-resolution factional >frequency multiplication factors. The toggling frequency >should obviously be well above the PLL's loop filter bandwidth. >I believe I can achieve the required divisor resolution with >32-bit counters. What's the spectrum of the output of a "two-modulus prescaler"? What's the spectrum of a DDS? How low do I have to make the PLL bandwidth if I want to filter out the junk? (Assume I run the DDS output through a PLL to filter out the steps.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 97296
On 20 Feb 2006 00:18:00 -0800, "Sunny" <shiladitya.biswas@gmail.com>
wrote:
>Hi
>I am writing synthesizable Verilog code for a DPRAM. It has two ports,
>Port A and Port B.
>For each port theres is a separate clock and separate clock_enable.
>This is the code I wrote
>
>reg [ 4: 0] read_addr_a;
> reg [ 4: 0] read_addr_b;
>
>always @ (posedge clock0)
> if (clocken0)
> begin
> read_addr_a <= address_a;
> read_addr_b <= address_b;
> end
>
> always @ (posedge clock1)
> if (~clocken0 & clocken1)
> begin
> read_addr_a <= address_a;
> read_addr_b <= address_b;
> end
>
>Can't resolve multiple constant drivers for net "read_addr_a[4] in the
>begiing of the first posedge block.
> Even though read_addr_a and read_addr_b are having multiple drivers
>but they are in different clock domains and different clock enables are
>being used.
>
>How can I resolve this. I am using Leonardo Spectrum and Precision RTL.
>
>TIA
>Sunny
The problem is that you're trying to write to both address registers
using both clocks. Think about the hardware and you'll realize that
this is not necessary. read_addr_a should be written by clock0 by
clken0 only and the similarly for read_addr_b, ie
always @ (posedge clock0)
if (clocken0)
begin
read_addr_a <= address_a;
end
always @ (posedge clock1)
if (clocken1)
begin
read_addr_b <= address_b;
end
Also as these are different clock domains you should never sample the
enable of side a with clock of side b without taking proper
precautions.
HTH.
Article: 97297
I downloaded the latest Xilinx service pack today and I'm now seeing
Map fail for a pre-existing design. Lat week I started porting the
design from the 6.1.03 s/w release to the 8.1.01 release. I had some
timing errors in the initial port, so I decided to download the latest
s/w updates before proceeding much further.
Now Map fails. I see no indication of any errors, the map report
looks fine, but I get the following output:
Mapping completed.
See MAP report file "chiptop_map.mrp" for details.
Process "Map" failed
Anyone else seeing this problem?
John Providenza
Article: 97298On Mon, 20 Feb 2006 19:47:16 +0100, Falk Brunner <Falk.Brunner@gmx.de> wrote: >Marko schrieb: >> Traditionally, firmware was defined as software that resided in ROM. >> So, my question is, what do you call FPGA code? Is "firmware" >> appropriate? > >Why not? Are you answering my question with a question? Seriously, I just want to know what other people call it. It seems incorrect to refer to FPGA code by the same name used for ROMable S/W. At my previous job, we just called it "FPGA Code". At my new job, it's called "firmware".Article: 97299
Thank you for the response, it was reassuring. I am in the process of taking a closer look at the timing margins at the controller on our Agilent infinium (2.25Ghz BW) scope and hopefully will be able to verify your suspicion. Additionally I have a comment; very rarely when the read cycles fail I only see one single rising edge on DQS as opposed to the four I would expect for an 8 burst read. I know that I am "catching" all the DQS transisitions as I am looking at the line over multiple read cycles. Have you seen this behavior before? Regards, Brendan "PeteS" <ps@fleetwoodmobile.com> wrote in message news:1140445121.929435.112130@g47g2000cwa.googlegroups.com... > Brendan Illingworth wrote: > > Hi All, > > > > This post pertains to a DDR SDRAM controller that works perfectly for 95% of > > DIMMS used, and is part of a test system that contains a 2+ GHz oscilloscope > > monitoring the clock, command, and dqs signals at the DIMM pins. > > > > Several DIMMs seem to operate incorrectly only occassional (possibly > > temperature dependent), and I suspect that the issue is some type of timing > > requirement that is on the edge of met and violated. When the incorrect > > behavior is seen the scope verifies that write cylces are operating > > correctly but that the read cycles are not operating correctly. Durring the > > read cycles the active command is issued, then the read command (satisfying > > Trcd) and accordingly the DQS signals are provided by the DIMM. Here is the > > catch; bursts of 8 was specified durring initialization and the DQS signals > > durring correct operation correspond to this choice; however, but durring > > the failing read cycles I will see sometimes 1 DQS rising edge, sometimes 2 > > and sometimes even 5 rising edges! My questions are as follows: > > > > 1) Has anyone with DRAM exprience seen any behavior like this before? > > > > 2) ** What might cause a DDR module to provide a varying number of DQS > > strobes? ** > > > > Recall that the design has no blatent errors since for most DIMMs no errors > > are ever seen. > > > > Thanks for any thoughts, > > > > Brendan Illingworth > > Most DDR problems are on the read cycle. > > When you do a read, DDR (unlike other memory) drives not only the bus > but also the strobes (as you are clearly know). What you may not know > is the amount of variance there can be between devices on the DQS <-> > data jitter and DQS (read) - clock variance. > > For those DIMMs you are having problems with, the issue is very likely > that DQS is being asserted outside your timing window (so the device > is, in fact, asserting a burst of 8 - you simply are not catching it). > > I have seen this behaviour using commercial parts with DDR controllers > built in - the programmable parameters such as DQS skew being there to > get around issues just such as this. > > The causes for this are usually either poor clock/data termination (and > in DDR you have to have something even if it's only series, which is > do-able in point to point), excessive round trip delay on the clock, > excessive added data skew (across D0-Dn vs. DQS) or excessive skew on > DQS vs. clock (which moves DQS as received away from the clock) as seen > at the receiver. > > In addition, DDR is not specified to operate below certain speeds, > although *most* will. This is a classic gotcha where the internal DLLs > won't properly lock to generate read DQS appropriately. > > The temperature dependency is perhaps to be expected - all logic > devices tend to operate a little slower (edge response in particular, > but propagation delay tends to increase as well), thus increasing the > amount of time before a return DQS is asserted. > > My first place to look would be DQS skew timing (remembering that the > memory device will assert DQS at the leading edge of data - it's up to > the controller to determine how to use it to grab the data) in the > controller. > > It took me almost as long, perhaps longer, to set the rules for laying > out DDR (I put down 3 independent 200/400 systems on one board) as it > did to get it laid out. Even then, my timing budget had about 200 > picoseconds of guaranteed margin - just what the guaranteed margin is > on any particular DIMM is I can't say without a datasheet handy. > > Cheers > > PeteS >
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